Comments 111
Веб сложный не потому что сложный, а потому что пресловутые «требования бизнеса» требуют, чтобы код/приложение/сайт был написан еще вчера, но вы все еще его пишете.
Чем быстрее написали код/запустили стартап/запилили сайт — тем быстрее (это распространенное заблуждение, потому что не всегда) «отобьются» расходы на этот самый сайт и он «начнет приносить прибыль».
А современный бизнес — это быстрее, быстрее, быстрее, обогнать конкурентов и урвать свою копеечку. Работа не на перспективу, а на сиюминутную прибыль.
В результате погони за скоростью создания того, что раньше делали месяца, а теперь хотят за два дня, сложность инструментов выросла. И чем быстрее надо решить задачу — тем сложнее инструмент, который эту задачу решает и тем больше нужно навыков для овладения этим инструментом. Закономерный процесс, ничего тут не сделаешь.
Ну ничего, сингулярность близко.
P.S.
Ну как-то же личная переписка в социальных сетях и интернет-банки работали 10 лет назад, когда веб был «проще»? :)
P.P.S. Разумеется, это все моё IMHO.
Чем быстрее написали код/запустили стартап/запилили сайт — тем быстрее (это распространенное заблуждение, потому что не всегда) «отобьются» расходы на этот самый сайт и он «начнет приносить прибыль».
А современный бизнес — это быстрее, быстрее, быстрее, обогнать конкурентов и урвать свою копеечку. Работа не на перспективу, а на сиюминутную прибыль.
В результате погони за скоростью создания того, что раньше делали месяца, а теперь хотят за два дня, сложность инструментов выросла. И чем быстрее надо решить задачу — тем сложнее инструмент, который эту задачу решает и тем больше нужно навыков для овладения этим инструментом. Закономерный процесс, ничего тут не сделаешь.
Ну ничего, сингулярность близко.
P.S.
современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках.
Ну как-то же личная переписка в социальных сетях и интернет-банки работали 10 лет назад, когда веб был «проще»? :)
P.P.S. Разумеется, это все моё IMHO.
UFO just landed and posted this here
Хочется в это верить ;)
Большинство фреймворков уйдут, но кто-то останется и станет повсеместно используемым, как стандарт де-факто. Поскольку фреймворк — это куча готовых наработок, которые писать с нуля под каждый проект никто не будет.
И это не особенность веба, в игрострое есть Unity и Unreal, например.
Единственное возможное исключение, это гиганты отрасли типа Google и FaceBook, которые могут поддерживать полностью самописную огромную кодовую базу.
Хотя, если посмотреть, то именно они сейчас и являются разработчиками популярных фреймворков и продвигают их в массы:Bootstrap (Twitter), Angular (Google), React (FaceBook)…
И это не особенность веба, в игрострое есть Unity и Unreal, например.
Единственное возможное исключение, это гиганты отрасли типа Google и FaceBook, которые могут поддерживать полностью самописную огромную кодовую базу.
Хотя, если посмотреть, то именно они сейчас и являются разработчиками популярных фреймворков и продвигают их в массы:Bootstrap (Twitter), Angular (Google), React (FaceBook)…
Make jQuery Great Again
UFO just landed and posted this here
Вы в node_modules давно последний раз заглядывали? Сколько там у вас версий $, штук 5 минимум наверное?)
А то как не копнёшь jq хейтера, так в его поделии внутре бутстрап без кастомизации, и да, jquery-3.3.1.
А то как не копнёшь jq хейтера, так в его поделии внутре бутстрап без кастомизации, и да, jquery-3.3.1.
UFO just landed and posted this here
То есть это единственная причина лютейшего хейта PHP и jQuery у всех? Ясно…
UFO just landed and posted this here
Понятно, просто сам факт того, что у людей просто как-то нереально бомбит от знака доллара, вот я и пытаюсь установить причину острот на эту тему, то есть как-будто бы знаки доллара тормозят прогресс и развитие языка.
UFO just landed and posted this here
Позвольте-с, это же все бессмысленная писанина) Да и я не совсем понимаю что значит «кто-то будет это читать»? Это же не собственные конструкции, из-за чего нужно искать написавшего это и спрашивать что он имел ввиду, это базовые лексемы языка, это все-равно что считать что в языке каком-то слова не нужны, на нем же будут говорить, какой ужас)
Недавно проводил исследование на тему, могу ли я писать компоненты на чистом стандарте (Web Components) и без фреймворка. В итоге все равно пришлось обмазаться дополнительными либами, потому что стандарт не решает большей части проблем. Даже доклад потом прочитал.
Это и с бекенду применимо, но бекенд пока не на столько сложен.
UFO just landed and posted this here
На собственном опыте.
Работали с проектами уровня хотя бы ВК?
Управление производством зубных коронок подойдет?
И почему в «проектах уровня ВК» бекенд усложняется, а фронтенд нет?
И почему в «проектах уровня ВК» бекенд усложняется, а фронтенд нет?
Управление производством зубных коронок подойдет?
Нет
И почему в «проектах уровня ВК» бекенд усложняется
Потому что производству зубных коронок, скорее всего, не требуется обрабатывать 75 тысяч сообщений в секунду со всего мира (не говоря уже об аудио и видео)
(А про фронтенд я ничего не говорил)
Потому что производству зубных коронок, скорее всего, не требуется обрабатывать 75 тысяч сообщений в секунду со всего мира (не говоря уже об аудио и видео)
Рискну предположить, что соотношение числа проектов, которым надо обрабатывать 75 тысяч сообщений в секунду со всего мира, к числу проектов, нагрузка на которые не требует никаких хитрых инженерных решений, составляет примерно 1 к неисчислимому легиону. Так что опыт разработки софта для управления производством зубных коронок вполне себе репрезентативен.
High load — основная сложность в backend?
На моем опыте масштабирование уже достаточно хорошо решенная задача. В какой-то момент приходится отказаться от баз данных с развитыми языками запросов и переходить на noSQL, но с этим можно справиться.
На моем опыте масштабирование уже достаточно хорошо решенная задача. В какой-то момент приходится отказаться от баз данных с развитыми языками запросов и переходить на noSQL, но с этим можно справиться.
На моем опыте масштабирование уже достаточно хорошо решенная задача.
Очень странно, во ВК видимо говнокодеры сидят, что у них задачи на бэкенде нередко занимают кучу времени с миграциями по полгода, о чём они даже завели целый блог на хабре
и переходить на noSQL
То есть фактически переписывать бэкенд почти с нуля
но с этим можно справиться.
И у вас уже есть такой опыт, что вы так смело это утверждаете? Мне вот одного лишь блога ВК уже с лихвой хватает, чтобы сильно сомневаться в подобного вида утверждениях
Моё ИМХО — проблема не в заказчиках, а в платформе. Веб сложный потому, что он изначально вырос из инструментов, которые не предназначались для создания приложений, и год за годом набирал тонны абстракций, каждая из которых тянула груз обратной совместимости. И мы теперь пишем сложнейшие приложения, используя для этого язык разметки текста и разросшийся скриптовый язык, причем не особо эффективный и не особо продуманный. Просто оказавшийся в нужное время в нужном месте.
В хаотических системах генетические алгоритмы часто бывают эффективнее редукционистского подхода. И это хорошо — это позволяет молодым и гибким конкурировать со старыми и тяжеловесными. Поэтому да, скорость — важнее, потому что достижимая точность предсказаний (оценки перспективы) в быстро-меняющейся среде очень низкая.
И скорее всего он на самом деле хочет, чтобы процесс разработки этих систем был сложным, тяжелым, но надежным и не дающим сбоев.
нет, он должен быть простым и надёжным, а для этого надо использовать правильные инстурменты, а не делать приложения с помощью технологий созданных для гипертекста.
Вот пример технологии, которую делали люди с пониманием того как оно должно быть.
UFO just landed and posted this here
Понятно, что это исследовательские проекты и там всё далеко от идеала, и наверное надо было дать ссылку не на этот проект, в нём действительно не так все хорошо, а на исходный, где подход именно компонентного интерфейса т.е. по сути не должно быть разницы под какую платформу делать приложение — должно быть декларативное описание гуя в терминах компонентов, таблица стилей и код обработки, а реализация под кокретную платформу, в том числе веб, это где-то там, под капотом. Веб не должен быть особой платформой, для этого нет никаких оснований — приложения и приложения, клиент-сервер такой же как везде.
Вы сейчас описали архитектуру React. Там тоже есть разделение на платформо-независимое ядро React и отдельные имплементации под платформу:
- react-dom — браузеры
- react-native — мобильные приложения
- react-art — графика на SVG или Canvas
- react-test-renderer – примитивный рендерер для тестирования компонентов
Есть и гайд о том, как написать свой кастомный рендерер. В принципе, все так же, как и в вашем описании, разве что используется Javascript вместо Python, но это уже вкусовщина.
UFO just landed and posted this here
Не факт.
JSON удобен для обмена небольшими блоками информации, но если написать на нем размер средней страницы современной, то в ее коде сложней будет визуально ориентироваться. Наличие закрывающих тегов у блочных элементов это плюс при анализе большой простыни верстки — понятней где что заканчивается.
JSON удобен для обмена небольшими блоками информации, но если написать на нем размер средней страницы современной, то в ее коде сложней будет визуально ориентироваться. Наличие закрывающих тегов у блочных элементов это плюс при анализе большой простыни верстки — понятней где что заканчивается.
Мне вообще иногда кажется, что история была такая:
2000 е: Ох уж эти Сшиники! Все их любят, все их ценят, они делают богоподобную работу. А вон там сидят Джависты — у них куча сложнейших объектов, рабочих проектов, куча абстракций, какие вещи они творят! А мы? Чего мы то делаем? Мы сидим и днями и ночами задрачиваем вёрстки на IE6, Opera и Firefox! Вот бы и нас так ценили и уважали как их… А давайте придумаем своих сложных абстракций и инструментов, чтобы тоже резко повысить вход в профессию? Тогда и предложение упадет, и спрос вырастет, и зарплаты подрастут! Кроме глобальных конференций про Java появятся и конференции по нашим выдуманным тулзам! И чтобы постоянно доказывать нашу значимость и сохранять высокий порог входа, мы будем усложнять свои инструменты, делать абстракцию в абстракции, говоря что так всем будет только проще!/тэг сарказм
Сложно было на ванила скрипт и джейквери сайты делать в один файл с кучей собственно придуманных костылей.
А сейчас благодать, куча фреймворков и инструментов, язык развивается, куча подходов к построению приложений.
А сейчас благодать, куча фреймворков и инструментов, язык развивается, куча подходов к построению приложений.
Веб не сложный, просто старый и костыльный. По сути все браузеры вместе с CSS и Javascript и HTML — нужно закопать и забыть, разработав при этом что-то современное.
И получится как всегда:
Да, то ли дело одна современная ОС для мобильных устройств. В ней нужно для каждого сайта скачивать и устанавливать приложение, внутри которого все те же самые код Javascript и разметка XHTML. Просто API другое.
Ничего, скоро так будет и в десктопных браузерах. С перспективой внедрения WebAssembly это уже совсем не шутка.
Ничего, скоро так будет и в десктопных браузерах. С перспективой внедрения WebAssembly это уже совсем не шутка.
А на вопрос так и не ответили, а все ведь просто. Потому что раньше компьютеры пользователей были слабыми и сессионное состоние пользователя хранилось на сервере/мейнфрейме (в памяти/сессии).
Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.
Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.
Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.
Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.
UFO just landed and posted this here
Правда, сейчас типичный SPA на медленных каналах просто не загружается, а медленные браузеры разработчики вполне целенаправленно отказываются поддерживать, и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы».
Потому что сайты десятилетней давности имеет довольно простой фронтент, там сервер делает отрисовку страниц, хранит состояние сесси и тд. Но это только про начальную загрузку страницы. В случае SPA переход между «страницым» почти не ощущается тк все страницы по сути уже подгружены, нужно только вызвать простой Rest ендпоинт чтобы получить данные для отрисовки в шаблон.
Все потому, что изначально задуманные веб-страницы «внизапна» стали не веб-страницами, а веб-приложениями.
Перетягивание одеяла от клиента к серверу было и будет: сначала были мейнфреймы с терминалами, каждое нажатие клавиши обрабатывалось «на сервере» и (т е на мейнфрейме) и передавалось на него, когда появились персоналки, то все, включая вычисления, перетекло на «клиент» (в связи с возросшей его мощностью), а по сетям гонялись только общие данные.
Потом появился интернет и браузеры, и начато было с того же — клиент фактически голый и ничего не умеет, зато «централизация». Потом клиент начал обрастать и обрастать, вспомогательный встроенный скриптовой язык стали использовать не для простых визуальных эффектов, а для построения той или иной логики, опять же, все уменьшая и уменьшая роль сервера и обмен данными с клиентом.
Оно и логично — зачем гонять на сервер и обратно то, что можно посчитать и выполнить у себя? Постепенно отошли от изначальной концепции серверного рендеринга, предполагавшей при каждом изменении состояния перезагрузку страницы, появился аякс и перерисовка разметки на лету, по мере усложнения обратившаяся в клиентские фреймворки и рендеринг, а по сети опять гоняют только данные.
Ну и из-за обратной совместимости все эти фреймворки все равно всего лишь генераторы того самого изначально не предназначенного для таких целей js, что и дает такую сложность всей картины.
Перетягивание одеяла от клиента к серверу было и будет: сначала были мейнфреймы с терминалами, каждое нажатие клавиши обрабатывалось «на сервере» и (т е на мейнфрейме) и передавалось на него, когда появились персоналки, то все, включая вычисления, перетекло на «клиент» (в связи с возросшей его мощностью), а по сетям гонялись только общие данные.
Потом появился интернет и браузеры, и начато было с того же — клиент фактически голый и ничего не умеет, зато «централизация». Потом клиент начал обрастать и обрастать, вспомогательный встроенный скриптовой язык стали использовать не для простых визуальных эффектов, а для построения той или иной логики, опять же, все уменьшая и уменьшая роль сервера и обмен данными с клиентом.
Оно и логично — зачем гонять на сервер и обратно то, что можно посчитать и выполнить у себя? Постепенно отошли от изначальной концепции серверного рендеринга, предполагавшей при каждом изменении состояния перезагрузку страницы, появился аякс и перерисовка разметки на лету, по мере усложнения обратившаяся в клиентские фреймворки и рендеринг, а по сети опять гоняют только данные.
Ну и из-за обратной совместимости все эти фреймворки все равно всего лишь генераторы того самого изначально не предназначенного для таких целей js, что и дает такую сложность всей картины.
Рендеринг шаблонов/страниц в наше время это часть SPA функционала, и это стало происходить тоже потому что машины пользователей стали мощнее. В прошлые века отрисовку страниц делали на сервере (и сейчас иногда начальную делают — server side rendering в понятиях SPA).
UFO just landed and posted this here
А кому сейчас нужен типовой бэкенд? Тем кому нужен берут какой нибудь firebase и досвидания.
Бэкенд сегодня сильно изменился...
Шта? Кампьютеры пользователей были настолько слабыми, что я им сувал xml-ки в чистом виде, вот прям в наичистейшем виде, которые юзеры открывали прям в браузере, содержащие исключительно и только данные, с поверх навернутыми xslt-шаблонами с вообще любой версткой какой захочу, и html-дерево влет строилось у них на клиентских кампах, причем само, причем само смотрело что за данные и применяло нужный шаблон. Это был насколько помню 2003-2004 год, если не ошибаюсь. И подгружались прочие динамические шматки так же, тока через аякс ессно, но исключительно и только подгружались новые шаблоны, абсолютно понятные для понимания. А то что xslt имел зачатки ооп, и на основе шаблонов можно было влет городить производные шаблоны — про это вообще наверное знают единицы) Сайты строились наура, данные были сами по себе и это было изумительно, шаблоны были идеальные, строилось все на ооп и это было изумительно, верстка вообще никого не колыхала, с верстальщика оно бралось и в шаблоны вставлялось влет. Юзер же получал все это и обрабатывал у себя в итоговый html и это было изумительно.
Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
Когда кто-то жалуется на то, что современный веб стал слишком сложным, мне каждый раз хочется напомнить этому человеку, что этому современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках.И веб это доверие регулярно «оправдывает».
Чтобы сказать, что сложное, а что нет, нужно с чем то сравнивать, было бы круто тогда добавить какую то шкалу и разместить на ней.
сравнивать нужно с разработкой десктопных приложений на современных фреймворках типа qt и др, где например, никому в голову не приходит позиционировать компоненты с помощью таблиц стилей, есть элемент grid, а стили они для стилей.
В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов. При этом хочется отзывчивый дизайн, а не переписывание всей верстки три раза под каждый вариант.
Таблицы стилей не плохи для позиционирования, плохо то, что там есть куча разных, зачастую совсем не очевидных, способов сделать одно и тоже позиционирование (float, flexbox, grid). И вот с этим бардаком надо действительно бороться и приводить стандарты к какому-то одному отлаженному решению.
Таблицы стилей не плохи для позиционирования, плохо то, что там есть куча разных, зачастую совсем не очевидных, способов сделать одно и тоже позиционирование (float, flexbox, grid). И вот с этим бардаком надо действительно бороться и приводить стандарты к какому-то одному отлаженному решению.
Так десктопом сейчас не ограничивается, есть же мобильные платформы, и упомянутый ENAML заявляет переносимость на все платформы, как-то решили эту проблему без всего этого сумасшествия.
Хммм…
Enaml style sheets are a powerful feature which allow the developer to customize the visual appearance of a view independent from the view’s structural definition. The concepts and nomenclature used in Enaml style sheets are heavily based on CSS and WPF, but are adapted to the dynamic and declarative world of Enaml.Developer Guide
Да какие таблицы стили сейчас не проектируй они будут похожи на существующие, понятно почему, я так понял based именно в этом смысле.
Хотя не исключаю, что какие-то проблемы переползли, элемента grid когда смотрел не заметил, хотя смотрел бегло.
Хотя вроде там были элементы для группировки, вполне может быть и норм.
Хотя вроде там были элементы для группировки, вполне может быть и норм.
В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов
Как это нет? Наоборот, десктопные оконные ОС изначально предполагают, что окно вашего приложения может быть вообще любого произвольного размера, и вы должны это учитывать при построении интерфейса. Просто проблема адаптации под принципиально разные размеры окон в десктопных приложениях была решена централизованно и задолго до появления веба. А веб пошел по пути «давайте сейчас будем табличками верстать, потом в будущем как-нибудь поправим». При этом для каких-то востребованных фич у разработчиков стандартов веба не принято вводить новые атрибуты/теги/параметры. Если есть решение, основанное на «грязном хаке», оно будет там жить веками. Как, например, чтобы нарисовать треугольник/уголок, мы все делаем толстый бордер и с одной стороны не закрашиваем. Чтобы сделать в гриде перетекание элементов при изменении размеров окна, такого атрибута CSS тоже нет, достигается с помощью хитрожопого сочетания. И так везде. Такое ощущение, что все эти титулованные ребята, которые придумывают стандарты CSS/HTML, кроме самих стандартов, вообще ничего не пишут.
UFO just landed and posted this here
Расскажите об этом централизованном решении.
Оно очень простое — привязки элементов к границам контейнера, якоря, автозаполнение свободного пространства. Всё это неплохо решало проблемы масштабирования в 1990-е годы (если этим пользоваться, конечно). Сейчас, естественно, этого недостаточно — нужна поддержка разных layout'ов и корректное масштабирование шрифтов, чего тогда не было. Но не суть важно, речь была о том, что на десктопе гибкая адаптация под произвольные размеры была всегда, и веб в этом плане страдает не из-за какой-то уникальнйо проблемы, а лишь из-за неудобных инструментов её решения.
Нет, треугольничек можно через SVG рисовать.
Можно. А потом с помощью такой-то матери состыковать с бордером блока, к которому он должен приклеиваться. Адок ещё тот.
Grid layout это из коробки умеет.
Да, как я написал. С помощью хитрожопого сочетания настроек. Чтобы в гриде получилось корректное перетекание элементов, вы должны задать колонкам атрибут auto-fit и выставить ограничение на размеры. То, что оно после этого начинает перетекать, это называется «побочный эффект». А «умеет» — это когда есть атрибут вида «grid-columns-count: auto;»
Это та самая профессиональная деформация. Оно откровенно реализовано через задницу, но мы это воспринимаем как должное, просто потому что многие люди, изначально выросшие на вебе, просто не понимают, как оно может быть иначе, проще и удобнее.
UFO just landed and posted this here
UFO just landed and posted this here
То есть решение давно было, но его недостаточно? Вы сами себе противоречите.
Ни капли не противоречу. В 90-е годы, про которые я писал, были одни требования, сейчас другие, только и всего. Современные фреймворки для нативной разработки вполне себе им удовлетворяют.
Стоп. А зачем его приклеивать к бордеру блока? В исходной задаче такого не было.
А где вы там вообще «исходную задачу» увидели? Я вам никакую задачу не ставил, я всего лишь упомянул кейс, в котором нужный результат достигается через хитро закрученную задницу. От того, что я недостаточно подробно расписал условия кейса — что имеется в виду не какой-то непонятно зачем нужный отдельно стоящий треугольник, а самый обычный распространенный треугольник для маркировки текстовых блоков, например, в чатах или хинтах, суть не меняется.
Сформулируйте, пожалуйста, точную задачу, потому что вёрстка сильно зависит от того, что вы хотите получить.
Точно так же — хочу получить всего лишь самый популярный вариант расположения блоков, который чаще других вариантов подходит для всяких галерей, списков объектов и т.д… Чтобы они всегда занимали 100% по ширине, масштабируясь в некотором диапазоне, а при дальнейшем изменении ширины экрана перетекали.
UFO just landed and posted this here
Сложно — это написать платформонезависимую вейт-фри структуру данных. Там надо думать
А в вебе надо просто выучить дохрена всего
Но если к вам придет верстальщик и начнет рассказывать про то, что ему нужен react, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.
Не понял, что здесь такого? И почему верстальщик должен рассказывать об инструментах, используемых в работе? Он должен ими уметь пользоваться и работать в срок. И React и строгая типизация очень даже помогают для верстки, с серверным рендерингом, CSS-in-JS, технически стало верстать проще. Да и лэндинг точно так же состоит из компонентов и у грамотного специалиста, эти компоненты всегда под рукой. Готовые фреймворки для сетки, форм, кнопок и т.д. опять же. Например, semantic-ui-react — шикарная вещь
Вполне нормально, когда заказчик определяет стек технологий на котором должен быть выполнен проект.
Если у него простой лендинг, то зачем ему завязываться на навороченный стек технологий специалисты которого стоят на рынке очень не дешево, чтобы потом его поддержка была дороже? Это все равно что в булочную на камазе ездить.
Если у него простой лендинг, то зачем ему завязываться на навороченный стек технологий специалисты которого стоят на рынке очень не дешево, чтобы потом его поддержка была дороже? Это все равно что в булочную на камазе ездить.
Нормально, полностью согласен, хотя мы вроде говорили о том, когда предлагает специалист, а не заказчик.
Кажется я чего то не понимаю в ваших суждениях. По моей логике, чем дороже специалист, чем дороже его час, тем меньше ему требуется времени на разработку и поддержку. Иначе, какой смысл вообще в дорогостоящих специалистах?
Т.е. если специалист знает весь стек, то и поддержка будет дешевой, так как часов нужно в разы меньше, чем дешевого специалиста.
Кажется я чего то не понимаю в ваших суждениях. По моей логике, чем дороже специалист, чем дороже его час, тем меньше ему требуется времени на разработку и поддержку. Иначе, какой смысл вообще в дорогостоящих специалистах?
Т.е. если специалист знает весь стек, то и поддержка будет дешевой, так как часов нужно в разы меньше, чем дешевого специалиста.
Заказчик может быть не совсем чайником, и уж точно может узнать какие технологии доступней на рынке и по какой цене. При этом цели заказчика — работающий проект при минимуме усилий и затрат и цели разработчика — заработать как можно больше, могут не совпадать
Дорогостоящий специалист имеет смысл на серьезный проект, а так, сейчас этот специалист сделает ему визитку на самом навороченном стеке, а потом каждое мелкое изменение, то есть поддержку, будет оценивать в приличную сумму. А дешевый новичок уже эти изменения сделать не сможет, так как там мега-комбайн с кучей взаимозависимостей. Если та же визитка на простом Bootstrap сделана, то какую-то мелочь в ней и обычный админ поверхностно знакомый с веб-разработкой сможет подправить.
Да и в целом, чем больше технологий задействовано в проекте, тем дольше и соответственно дороже его собрать в рабочее состояние, натроить все зависимости и т.п…
Для сложных проектов это оправданная необходимость, которая будет экономить время на решение дальнейших сложных задач, а для сайта-визитки это лишние затраты ничем не обоснованные.
Грубо говоря, не надо множить сущности без меры. Если сайт визитка из 3-х страниц, то не надо туда тащить технологии которые разрабатывались для создания огромных порталов и социальных сетей — они слишком громоздки для мелких задач.
Дорогостоящий специалист имеет смысл на серьезный проект, а так, сейчас этот специалист сделает ему визитку на самом навороченном стеке, а потом каждое мелкое изменение, то есть поддержку, будет оценивать в приличную сумму. А дешевый новичок уже эти изменения сделать не сможет, так как там мега-комбайн с кучей взаимозависимостей. Если та же визитка на простом Bootstrap сделана, то какую-то мелочь в ней и обычный админ поверхностно знакомый с веб-разработкой сможет подправить.
Да и в целом, чем больше технологий задействовано в проекте, тем дольше и соответственно дороже его собрать в рабочее состояние, натроить все зависимости и т.п…
Для сложных проектов это оправданная необходимость, которая будет экономить время на решение дальнейших сложных задач, а для сайта-визитки это лишние затраты ничем не обоснованные.
Грубо говоря, не надо множить сущности без меры. Если сайт визитка из 3-х страниц, то не надо туда тащить технологии которые разрабатывались для создания огромных порталов и социальных сетей — они слишком громоздки для мелких задач.
Вы описываете не специалиста, а какого-то не очень честного разработчика. Ну да, можно еще трояны в код вставлять, а потом деньги вымогать за ремонт сайта. Вы знаете, для этого не нужен ни навороченный стек, ни дорогостоящий специалист...
Дело не в честности.
Программист может работать в качестве машинистки, набирая текст на клавиатуре, но это будет очень дорогая машинистка.
Точно также и тут получается, если задача поправить пару мелочей на странице, то у крутого специалиста это все равно будет намного дороже, чем у новичка, потому что это все равно время: обсудить задачу, подключиться к проекту, найти нужное место и т.п. не интересные и малопродуктивные траты времени, дорогого времени.
Программист может работать в качестве машинистки, набирая текст на клавиатуре, но это будет очень дорогая машинистка.
Точно также и тут получается, если задача поправить пару мелочей на странице, то у крутого специалиста это все равно будет намного дороже, чем у новичка, потому что это все равно время: обсудить задачу, подключиться к проекту, найти нужное место и т.п. не интересные и малопродуктивные траты времени, дорогого времени.
С ваших слов, чем человек профессиональнее, тем он хуже для заказчика, медленнее обсуждает задачу, медленнее подключается к проекту и т.д. Поэтому в итоге выходит дороже.
Я с этим абсолютно не согласен, считаю, что именно скорость всего вышеперечисленного и определяет качество специалиста. И да, время профессионала дороже, но на конечную цену это должно влиять только в сторону ее уменьшения, иначе это не профессионал, а зазвездившийся товарищ.
Я с этим абсолютно не согласен, считаю, что именно скорость всего вышеперечисленного и определяет качество специалиста. И да, время профессионала дороже, но на конечную цену это должно влиять только в сторону ее уменьшения, иначе это не профессионал, а зазвездившийся товарищ.
Я лишь хочу донести, что уровень профессионала и технологий должен соответствовать уровню проекта.
А я утверждаю, что дело не в технологиях.
Ну не вижу я технических причин долго вносить правки в лендинг, сделанный при помощи даже такого громадного количества слов React + TypeScript + CSS + HTML + Webpack + TSLint + Prettier + SemanticUI + VSCode + Windows/MacOS.
И у меня есть другая догадка, объясняющая ваши сомнения, основанная на собственном опыте. Не все заказчики способны работать с той же скоростью, что и профессионалы. И уровень проекта определяется не технической начинкой стека, а именно «начинкой» заказчика. (*под заказчиком подразумевается не обязательно человек).
Если заказчик, к примеру, требует работать только на удаленном рабочем столе, к которому нужно подключаться через VPN, доступ к которому нужно выпрашивать у админа полдня, через тормозящий интернет 50Кбит/с. Если каждое согласование проходит все ады бюрократии, то, действительно, преимущества профессионала в виде скорости становятся бессмысленными, большую часть времени ему придется сидеть и ждать ответа.
Но это никак не связано со сложностью стека технологий!
Ну не вижу я технических причин долго вносить правки в лендинг, сделанный при помощи даже такого громадного количества слов React + TypeScript + CSS + HTML + Webpack + TSLint + Prettier + SemanticUI + VSCode + Windows/MacOS.
И у меня есть другая догадка, объясняющая ваши сомнения, основанная на собственном опыте. Не все заказчики способны работать с той же скоростью, что и профессионалы. И уровень проекта определяется не технической начинкой стека, а именно «начинкой» заказчика. (*под заказчиком подразумевается не обязательно человек).
Если заказчик, к примеру, требует работать только на удаленном рабочем столе, к которому нужно подключаться через VPN, доступ к которому нужно выпрашивать у админа полдня, через тормозящий интернет 50Кбит/с. Если каждое согласование проходит все ады бюрократии, то, действительно, преимущества профессионала в виде скорости становятся бессмысленными, большую часть времени ему придется сидеть и ждать ответа.
Но это никак не связано со сложностью стека технологий!
Все гораздо проще.
Если, например, итоговую верстку надо будет интегрировать в проект на джанго или чем-то еще похуже без участия автора, то верстальщика, не способного отгрузить верстку в формате, который либо нечитаем, либо не поддерживает интеграцию с фреймворком без дополнительного тулинга, будут ненавидеть.
Разработчики не живут в их воображаемом мире, они взаимодействуют с другими людьми — другими разработчиками, лидами и архитекторами, прямо или опосредованно — с бизнесом, клиентами, заказчиками. Почти никогда человек не создает новый продукт один, а это значит, что результат компиляции — не единственный результат его работы. Исходники тоже обладают огромным количеством характеристик — понятность, внедримость в существующие процессы, сложность поддержки и так далее.
Почему веб такой сложный? Потому что
- Нужно поддерживать legacy из 90х годов
- Заказчик требует, чтобы сайт, по функционалу сравнимый с полноценным десктопным приложением, был написан за неделю.
- Потому что есть куча браузеров с разными реализациями
- Как и во всех индустриях, люди, которые меньше всего понимают, кричат громче всех.
- Заказчик требует «Новомодный_фреймворк», значит нужно им пользоваться!
UFO just landed and posted this here
Я вам очень сочувствую и советую найти другую компанию, где не занимаются воплощением безумных хотелок заказчика, а взаимодействуют конкретно с бизнесом по time & materials, либо занимаются внутренней разработкой. Там, к счастью, есть понимание сложности и сроков разработки, цены поддержки старых платформ (она гигантская), и есть люди, умеющие напомнить заказчику, что ему нужен веб-сервис, который приносит деньги, а не повод для хвастовства про технологии.
P.S. в моей практике случалось требование технологии (причем в формате "бан на технологию") во фронтэнде только единожды, причем по юридической причине.
React и его история с файлом Patents?
Нет, не это. К сожалению, не считаю этичным рассказывать подробности и описывать что-то конкретное.
Если говорить совсем абстрактно — был риск примерно той же истории, что была с ReactOS, когда слили исходники винды — им все пришлось провести аудит всего кода, чтобы убедиться, что ничего не скопировано/не переписано из исходников винды, решили, что проще на всякий случай отказаться от технологий.
В итоге под запретом был конкретный технологический стек. Приятно было то, что он в основном был весьма "ретро", поэтому все с радостью выдохнули, узнав, что не надо будет мучиться с старьем. В случае с фронтом был запрет на ангуляр 1, ну и "на всякий случай" на ангуляр 2 и выше.
www.npmjs.com/package/quokka-script — один из промежуточных итоговр у ребят.
github.com/obitel/fw — когда-то давно была такая задумка (код не нахожу, не помню имя репы)
github.com/obitel/fw — когда-то давно была такая задумка (код не нахожу, не помню имя репы)
Появился GraphQL, решающий проблемы со сложностью описания, документирования и поддержания REST.
IMHO GraphQL больше об агрегации данных, чем об улучшении REST. Является всего лишь подмножеством REST и невозможно использовать HATEOAS в GraphQL.
GraphQL является просто другим уровнем по OSI. Он может работать поверх хоть REST, хоть WebSockets, хоть голого TCP по факту, но наиболее частое использование поверх rest-а, это правда.
Он решает проблемы, которые накладывали глаголы REST, потому что стандартных действий get-post-put-delete в общем случае недостаточно, решает проблемы с описательными возможностями get-запросов, и проблемой с необходимостью запроса одной сущности с разными "линзами", и бонусом дает решение огромной кучи проблем с кэшированием (но не всех, да).
К сожалению, HATEOAS вживую нигде не встречал, не могу понять его плюсы и прокомментировать.
Пост автора ели дочитал, комментарии ближе к сути.
Я как Джун заставший то время и реснулся в это могу сказать, что люди которые говорят, что все это жесткое извращение — реально правы.
Может у меня мало опыта, но примитивным хтмл я и чище и качественней сверстаю, чем Джун используя все извращения...
Уже кто-то написал:
и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы»....
Я лично вижу усложнение всего из-за того, что из ксс и хтмл пытаются сделать яп каковыми они не являются… а делают это как раз те кто на прямую не пишет верстку, а лишь программит на её основе… вот и решили мол в баню верстальщиков, сейчас я как придумаю какой нить дроч и буду кодить верстку… это как лопатой и косить и накидывать сено… придумывают мега комбайны для полей размером с палисадник… Все
UFO just landed and posted this here
Могу еще раз, но простым языком — все фронтэндеры мнят себя дохрена инженерами и хотят закладывать возможности "по-максимуму", поэтому те инструменты, которые решают 20% самых сложных задач, и выглядят круто, но которыми надо уметь пользоваться и контролировать, тащат к себе абсолютно все, чтобы потом на митапах хвастаться. А остальная часть поста — это про то, из чего эти 20% задач состоят, и почему оставшимся инженерам они важны.
Ну не знаю… по-моему веб не сложный. Для меня сложно, это когда говоришь iOS программисту, сделай, плиз, чтобы вот этот компонент работал чуть по-другому. А он такой, сорян босс, но встроенный компонент такое не поддерживает, поэтому надо писать кастомный, неделя минимум. И ты такой, :facepalm:, потому что такое на веб-стеке за пару дней можно сделать, со всеми свистелками и перделками от дизайнера.
И ты такой, :facepalm:, потому что такое на веб-стеке за пару дней можно сделать, со всеми свистелками и перделками от дизайнера.
В общем случае программист iOS тоже так может. Но не хочет.
Все возможно)
Что значит возможно? И что значит хочет/не хочет? Есть мануалы и прочие доки, где указано как и что лепить в иос. Общий вид компонентов здорово стандартизован. А в таком случае зачем делать кастомные «свистелки и перделки от якобы дизайнера»? Смысл же отсутствует. Напрочь отсутствует. Может «якобы дизайнера» носом тыкнуть в мануалы по иос, ну что бы уже не лепил никогда никому непонятную хрень?
Есть мануалы и прочие доки, где указано как и что лепить в иос. Общий вид компонентов здорово стандартизован.
Полагаю что дело именно в этом.
А в таком случае зачем делать кастомные «свистелки и перделки от якобы дизайнера»? Смысл же отсутствует.
Потому что заказчики обычно не хотят «общий вид компонентов», «стандартных решений» и «быть как все». Я то может и соглашусь с тем, что юзеру чаще всего удобнее использовать привычные решения. С другой стороны, можно понять авторов приложений, которые хотят, чтобы их интерфейс был максимально преспособлен к конкретно их задаче.
Короче это палка о двух концах и не нужно уходить в крайности.
Потому что заказчики обычно не хотят «общий вид компонентов», «стандартных решений» и «быть как все»
Я не претендую на тотальную объективность, но по моему личному опыту подавляющее большинство заказчиков прислушиваются к замечаниям вида «так делать не принято и ваше приложение будет выглядеть непрофессионально». А вариант «окей, мы это можем сделать, но это будет стоить 3 цены от той, что вы ожидаете» — это эффективный «аварийный» аргумент, когда другие методы на заказчика не действуют. В конце-концов, если заказчик настолько упрямо, что согласится, то за трехкратную наценку и самому разработчику легко полюбить и работу, которую делать откровенно неинтересно, и результат откровенно не нравится.
Все зависит от специфики приложения. Встроенные компоненты далеко не всегда дают приемлемый пользовательский опыт, когда речь идет не о приложении с фоточками. Это первое. Во-вторых, я говорю даже не о вариантах, когда заказчит хочет компонент, полностью отличный от стандартного. Бывает так, что нужно поменять прям какую-то ерунду, по мнению заказчика, по типу «как это вы не можете сделать, чтобы этот label был на пару пикселей ниже? разве мы многого просим?». По факту нативный компонет реально не предоставляет таких возможностей и в этом случае очень трудно объяснить заказчику почему такая мелочь должна решаться так дорого. Часто это лишь приводит к тому, что заказчик начинает сомневаться в компетенциях исполнителя.
Sign up to leave a comment.
Почему веб такой сложный?