Найбільша PHP конференція України, 1 червня: хто буде і чому варто відвідати?
×Закрыть

Как стать full stack разработчиком, зная back-end. Пошаговая инструкция

Всем привет, меня зовут Влад, и я уже более семи лет занимаюсь коммерческой разработкой. Ранее я писал, как найти первую работу, как готовиться к собеседованиям и как учить .NET.

Сейчас я работаю в компании DataArt. Мой основной стек технологий — экосистема .NET, но почти во всех проектах я занимался также и front-end частью. В этой статье я попытаюсь сформировать общее понимание современной front-end экосистемы для людей, уже имеющих опыт в разработке, неважно, на каких back-end технологиях. И дам базовые рекомендации тем, кто хотел бы расширить свою область компетенций.

Зачем это нужно

Сейчас на рынке есть некий тренд на full stack специалистов, способных реализовывать все части проекта, а не только какую-то одну. Этому есть множество объяснений:

  • Синхронизация между front-end и back-end командами требует времени и некоторых технических средств (swagger, версирование API). Чем больше людей нужно синхронизировать, тем выше вероятность ошибки из-за человеческого фактора. Очень часто люди сталкиваются с проблемой, что кто-то забыл обновить эндпоинты либо отправляет данные в неправильном формате. Это все решаемо, но выяснение причин и устранение таких ошибок требует времени.
  • Очень часто в промышленной разработке клиент не имеет до конца сформированных требований либо требования изменяются, что приводит процесс разработки к небольшим итерациям и изменениям «на ходу». Если в таких условиях сложно разделять задачи, договариваться о «контрактах» между частями приложения, то это будет значительная потеря времени и производительности.

В общем, если сравнить pros & cons разделения ответственности, я пришел к такому сравнению:

Разделение разработки между front-end и back-end командами/людьмиFull stack
Минусы:
  • Более дорого для небольших проектов.
  • Слабо подходит для ситуаций неопределенности, необходимы четкие требования.
  • Вероятность ошибок растет нелинейно с необходимостью синхронизации.
Минусы:
  • Качество реализации front-end-части, скорее всего, будет страдать.
  • Для сложных проектов люди будут работать медленнее, распыляясь.
Плюсы:
  • Более компетентная front-end-разработка, лучшее качество кода и более правильное решение сложных задач.
  • При наличии четких требований и параллельной разработке — более быстрая реализация.
Плюсы:
  • Более гибкая разработка.
  • Более дешево для небольших проектов.
  • Более эффективная разработка в ситуациях неопределенности.
  • Кросс-функциональность и взаимозаменяемость членов команды.

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

Первые шаги

Если вы все-таки решились, будьте готовы к тому, что современная front-end экосистема очень изменчива, постоянно выходят новые версии фреймворков, ломая обратную совместимость. То, что вчера было стандартом, сегодня уже устарело. Это имеет свою логику: сам веб развивается достаточно быстро вместе с самими браузерами, меняются и требования к разработке. Также вы сразу же столкнетесь со шквалом непонятных ошибок — на всех уровнях. Будьте готовы много гуглить или спрашивать у коллег. Не зря front-end комьюнити самое активное в плане конференций и контрибуции open source, иначе просто не выжить.

Например, вот таблица поддержки разными версиями и производителями браузеров разных версий JavaScript. О том, как преодолевается такая неразбериха, — далее в статье.

Немного о том, что такое современная front-end-разработка. Если вы писали на JQuery, это не совсем то, это скорее веб-мастеринг, добавляющий динамику страницам. Если вам нужно добавить простые эффекты на landing page либо реализовать несложную логику всплывающих окон, это верный путь, но если вы пишите полноценное одностраничное веб-приложение (Single Page Application), то это явно путь в никуда. Можете оставить свой предыдущий опыт с JQuery и обучаться заново, иначе разработка произведет огромный технический долг, который поглотит ваш проект, и каждое следующее изменение будет почти невозможным без переписывания значительной части.

Также немного о базовых понятиях. Правильное название JavaScript — ECMAScript (ES), JS — это маркетинговое название. Второй важный момент: Angular и AngularJS — это разные фреймворки. AngularJS — это все, что до версии 2.0, Angular — это все, что после второй версии. Это абсолютно разные параллельные ветки. Angular версий 2 и 7 отличаются не так сильно, просто политика версирования. Говоря «front-end-фреймворк», мы также для простоты имеем в виду библиотеки вроде React.js и Vue.js вместе с их экосистемой.

Общая структура знаний и технологий

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

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

Инфраструктура и сборка проекта

Пакетный менеджер

По аналогии с любой другой средой разработки — gems в Ruby либо packages из Nuget — в .NET для front-end есть системы управления пакетами:

NPM (Node Package Manager) — наверное, самая популярная система управления пакетами. Ее основная задача — вычитать имена и версии пакетов из package.json и разворачивать их вместе с зависимостями в папку node_modules. Имеет глобальный кеш пакетов (по аналогии с GAC.NET). Пакеты могут быть служебными (devDependencies) и обычными, включаемыми в production-сборку. Ссылка на официальный репозиторий пакетов.

Yarn — устанавливается с помощью NPM, что позволяет ускорить процесс установки, а также обеспечить другие полезные функции, недоступные в NPM, по умолчанию смотреть на зеркало npmjs от Facebook.

Bower — уже неактуальный менеджер пакетов, смысла разбираться с ним нет. Устанавливается с помощью NPM, но имеет свою базу пакетов. Ранее имел фичи, не реализованные в NPM, однако уже устарел, на сайте Bower есть рекомендация переходить на Yarn или NPM.

CLI

Каждый фреймворк имеет свой Command Line Interface (CLI) для выполнения разной черновой работы: скаффолдинга проектов с заранее заданными настройками, добавления компонентов, запуска тестов, деплоя, анализа производительности.

Angular — Angular CLI
React — Create React App
Vue — Vue CLI

Модульная архитектура проекта

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

  • ES-модули — самый популярный стандарт, тот самый import {classname} from.
  • CommonJS — встроенная в NodeJS система организации модулей.
  • AMD (asynchronous module definition) — стандарт, который реализован в системе RequireJS, считается устаревшим.

Более подробно можно почитать тут.

Система сборки модулей и таск-раннеры

По сути, это тот же NPM-пакет, который запускается инфраструктурным кодом для превращения ваших исходников в веб-приложение, готовое к запуску. Самые популярные системы сборки:

  • Webpack, Browserify — системы сборки со множеством фич из коробки. Для большинства случаев вполне приемлемо использовать Webpack.
  • Gulp, Grunt — являются, по сути, таск-раннерами, имеют экосистемы из большого количества плагинов. С их помощью можно воссоздать ту же цепочку обработки и сборки и даже запустить Webpack как отдельную задачу.
  • NPM scripts — альтернатива Gulp/Grunt. Предлагается делать эту же работу чисто на менеджере пакетов NPM с его возможностью подключать зависимости для разработки, добавлять сложные команды в раздел scripts у package.json.

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

Если взять, к примеру, Webpack, то придется немного повозиться, чтобы настроить все необходимые параметры и пакеты с нуля, для сборки/минификации скриптов, транспайлинга/полифила, сборки и преобразования CSS, HOT loading (обновления вашего приложения после сохранения без необходимости обновлять страницу).

Для этого имеет смысл воспользоваться CLI для скаффолдинга (генерации основы приложения/модулей) готовых настроек и пакетов для файла webpack.config.js.

Транспайлеры/полифилы

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

Тут нам на помощь приходят:

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

Например, самый популярный пакет Babel является и транспайлером, и полифилом. Поддерживает ES6/TypeScript, JSX, Flow, переводя код, написанный на этих языках, в ES5, понятный всем браузерам.

Транспайлеры/полифилы — обычно одни из шагов обработки исходного кода с помощью сборщиков/таск-раннеров.

Линтеры

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

Форматеры кода

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

Unit/UI-тесты

Аналогично с back-end время от времени существует необходимость в написании тестов. Но виды тестов немного отличаются.

  • Тесты в BDD подходе / Unit тесты— это три в одном: и тесты, и документация, и примеры использования. Тут вам помогут Jasmine/Mocha.
  • Интеграционные тесты — проверяются отдельные элементы верстки на корректность и работоспособность.
  • End-to-end-тестирование — через обертку над Selenium Web Driver, например, реализуется в Mocha. Проверяется весь флоу взаимодействия, где покрываются только позитивные сценарии.
  • Визуальное тестирование — тестирование на соответствие верстки заданному виду, например: PhantomCSS, Wraith, более продвинутые средства, вроде Applitools.

Понимать, что это такое, для общего развития стоит, но не думаю, что вам следует сильно углубляться в эту тему: чаще тесты пишут профильные front-end разработчики.

Разработка

Для разработки можно использовать как более тяжеловесные IDE вроде NetBeans/Visual Studio, так и более легковесные. Не столь важно, какую IDE или текстовый редактор вы будете использовать, сколько то, какие плагины вы поставите туда. Все эти IDE/редакторы имеют встроенную систему установки плагинов для навигации/отладки/подсветки синтаксиса и генерации кода. Разница между IDE и текстовым редактором заключается в том, что текстовый редактор более свободен от лишней функциональности, и только вам решать, какие плагины туда поставить. Со временем его сложность может стать не меньше, чем у IDE.

  • WebStorm — достаточно популярная и мощная, но платная IDE.
  • Visual Studio Code — больше текстовый редактор, чем IDE.
  • Sublime Text — чем-то похож на VS Code.

Что использовать вам — дело вкуса, лично я использую Visual Studio Code, но многие профессиональные front-end разработчики хвалят WebStorm. Full stack разработчики часто любят использовать ту же IDE, где они пишут и back-end. Например, в ASP.NET Core есть мидлвар для запуска front-end части синхронно с back-end.

Также необходимо освоить Chrome DevTools (F12 Tools) — очень мощное средство отладки и диагностики. В самых тяжелых случаях вам может понадобится Fiddler — сниффер трафика, позволяющий производить дебаг вашего взаимодействия с сервером.

Понимание клиент-серверной и сетевой архитектуры

Для начала выясните базовые вещи на уровне концепций протоколов транспортного уровня модели OSI.

  • Как работает DNS-сервер.
  • Что такое доменное имя.
  • Как, как и почему выделяется IP-адрес.
  • Что такое протоколы TCP/IP, UDP.

Далее возьмитесь за базовое понимание протокола HTTP. Сам по себе HTTP или его наследник HTTP/2 с сетевой точки зрения — это протокол прикладного уровня. По сути, это передача текста по протоколу TCP/IP. HTTP реализован на бумаге, в виде некоторой спецификации-рекомендации, как веб-сервер должен реагировать на определенное сочетание поступающего к нему текста. Мы можем послать, к примеру, в GET-запросе данные тела запроса, как в POST, но сервер их просто проигнорирует.

И в каком виде веб-сервер должен отдавать ответ браузеру? Разные веб-серверы (IIS, Nginx, Apache) могут по-разному реагировать на HTTP-запросы, однако тут отклонения от рекомендаций и различия очень незначительны.

Особое внимание следует уделить следующим разделам:

  • HTTP-статусы, основные.
  • HTTP-заголовки и реакция браузера на них.
  • Методы HTTP-запросов GET/POST/PUT/DELETE и другие, хотя на практике часто обходятся GET и POST.
  • Что такое Cookies, JWT/Bearer-токены.
  • Local storage — браузерное хранилище, как с ним работать и зачем.
  • Виды взаимодействия браузера и сервера — технические и логические техники:
    • AJAX/Polling;
    • Long polling;
    • Comet;
    • SSE;
    • WebSocket.

Более подробно можно почитать (посты 2012–2013 годов, тем не менее информативно):

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

Например, обмен сообщениями в реальном времени в ASP.NET реализован в виде фреймворка SignalR. Он сам выбирает транспортный уровень в зависимости от совместимости, тем самым скрывая эти подробности от вас. При использовании front-end фреймворков вам всего лишь нужно установить пакет для работы с SignalR.

  • XSS, CSRF — самые популярные уязвимости и методы борьбы с ними.
  • CORS — политика межсайтовых запросов, как сделать так, чтобы с одного домена можно было слать запрос на ресурс в другом домене.
  • JSON — самый популярный формат передачи данных в сети.

Язык

Сейчас самый популярный язык для front-end — это ECMAScript 6 / TypeScript. Если рассмотреть возможности языков с точки зрения множеств, то выйдет так:

ES5.1 — фактически стандарт, поддерживаемый почти на 100% всеми современными браузерами одинаково. О нем есть замечательная книга с носорогом под названием «Подробное руководство», которую я вам не советую читать: очень уж там много воды. Базовые вещи достаточно глубоко разобраны тут: javascript.ru/tutorial, learn.javascript.ru.

Критические вещи для понимания самого языка:

  • Области видимости переменных var.
  • Типы данных, включая функциональные.
  • Механика работы объектов и прототипов — достаточно общего понимания, при написании кода на ES6/TS вы вряд ли с этим столкнетесь.
  • Механика работы замыканий.
  • Приведение типов (без фанатизма!).
  • Работа с объектами браузера — window, document, HTML element.
  • Всплытие событий, работа с событиями.
  • Манипулирование DOM и селекторы.
  • Как работает асинхронность в V8.

Если вы знакомы с ООП-языками, то JavaScript — язык тоже объектно-ориентированный, со специфичной механикой наследования через прототипы. Тем не менее я думаю, что JS вполне себе разделяет концепции ООП:

  • Инкапсуляция — мы в праве хранить переменную, захватив ее в замыкании, сделав недоступной вовне.
  • Наследование — мы можем строить цепочки прототипов, расширяя их.
  • Полиморфизм — мы можем интерпретировать функцию как объект, все есть объект.

Быть профессионалом в ES5 необязательно, но базовое понимание не помешает.

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

TypeScript — является расширением ES6 и языком по умолчанию в инфраструктуре Angular. Рекомендую читать официальную справку. Тут появляются интерфейсы, generic, строгая типизация, ошибки времени компиляции. TS больше всего похож на C# и, пожалуй, является самым понятным подмножеством JS для back-end разработчиков.

Остальные языки экосистемы JavaScript:

  • NativeScript — является языком написания гибридных мобильных приложений.
  • CoffeeScript — диалект, отличается своей лаконичностью и читаемостью, однако не имеет большой популярности сейчас.
  • ELM — функциональный язык, имеет ограниченную сферу применения.
  • Dart — не совсем язык экосистемы JS, скорее, отдельный язык со своим интерпретатором, который встроен в Google Chrome.

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

Фреймворк и библиотеки

Angular / AngularJS

Я уже упоминал, Angular — это все, что после второй версии, а AngularJS — все, что до нее. Архитектурный паттерн, предлагаемый Angular, — это MV*/MVVM. Единого мнения нет, но в целом архитектура очень похожа на ASP.NET Web Forms — есть компоненты с вложенными компонентами и сквозной функциональностью — встроенный IoC-контейнер для инъекций сервисов в компоненты, управление scope. Обработка асинхронных операций обычно пишется на RxJS. Однако возможно использовать Angular совместно с контейнером состояний Redux.

Для освоения базовых вещей я рекомендую курс «Angular 7 (formerly Angular 2) — The Complete Guide». Также неплохой гайд для старта.

Работая с front-end, нужно понимать природу задач, решаемых программно. Взаимодействие с браузером можно представить в виде потока событий и реакции на них, а также синхронизации разных цепочек событий и их преобразования. Для решения таких задач применяют парадигмы реактивного программирования. Эти парадигмы реализованы в библиотеках Reactive Extensions для множества языков программирования. Для JS это RxJS. Справка по RxJS. По RxJS могу посоветовать доклад моего коллеги.

С точки зрения движка шаблонизации, Angular вполне напоминает тот же Silverlight с привязками данных.

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

React.js

Менее привычный подход для back-end разработчиков, с ориентацией на верстку и событийный поток. React.js, по сути, является библиотекой/template-движком, на котором вполне можно разрабатывать без дополнительных средств, однако это не настолько удобно при росте проекта и его сложности.

Говоря «React», мы подразумеваем React + React DOM для веб-разработки. Если взять React и React Native, мы сможем в похожем синтаксисе разрабатывать кросс-платформенные мобильные приложения. Для упрощения такой подход называют React Native. Подробнее тут.

Таким образом, сформировалась целая экосистема React:

  • Axios — для HTTP-запросов.
  • React Router — для поддержки более удобного роутинга.
  • Redux — для централизованного управления состояниями.
  • React Router Redux — для связи роутера и контейнера состояний.
  • Redux-Thunk / Redux-Saga / MobX — разные подходы для синхронизации асинхронных операций.

Самый популярный архитектурный паттерн в React.js — это Redux, эволюция идеи Flux. По сути, идея Flux — это тот самый знакомый CQRS для back-end-разработчиков.

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

Подход к разработке в React.js противоречит «классическому» — отделению кода от разметки. React имеет свой движок шаблонизации — JSX, который упрощает смешивание верстки и кода. Верстка вставляется прямо в код.

Из первых вопросов, которые стоит разобрать, я выделил такие:

  • JSX;
  • Components, lifecycle;
  • State/props;
  • Virtual DOM;
  • Synthetic events;
  • Unidirectional data flow;
  • HOC/Pure components;
  • Flux/Redux.

В качестве учебника вполне подойдет официальная справка.

Vue.js

Еще один популярный движок шаблонизации, построенный на архитектуре MVVM (с использованием VueX — это Flux). Он имеет несколько вариантов организации шаблонов:

  • Single File Components — концепция, в которой шаблон, логика и стили инкапсулируются внутри единого файла.
  • JSX — смесь верстки и кода, то же, что и в React.js.

Сам по себе Vue.js похож на React в том, что это лишь движок для шаблонизации, имеющий свою экосистему:

  • Axios — HTTP-запросы;
  • Vue Router — роутинг;
  • VueX — контейнер состояний.

Субъективно, Vue.js гораздо проще для старта, чем Angular или React. Он имеет отличную справку-руководство, в том числе русскоязычную.

Кратко о концепции потока данных в VueX:

Идея похожа на тот же CQRS:

  • Код из нашей верстки диспатчит Action.
  • Action делает асинхронный запрос на сервер.
  • После получения ответа вызывается Mutation, которая решает, как ей менять State.
  • Изменение State делает повторный рендер верстки.

Awesome Vue — тут вы найдете исчерпывающий список всего, что относится к экосистеме Vue.js: пакеты, гайды, UI-библиотеки, статьи.

Другие фреймворки и библиотеки

Backbone/Marionette, Ember, Knockout, MeteorJS, ExtJS, Aurelia — есть еще очень много различных фреймворков/библиотек, но:

  • Они не пользуются таким спросом, как раньше, хотя могут быть вполне подходящими для решения задач, возложенных на них. Я знаю людей, которые до сих пор хвалят Ember/Backbone+Marionette и будут использовать их в новых проектах ввиду хорошего их знания.
  • Их подход устарел.
  • Они имеют некоторую избыточность по сравнению с тройкой лидеров.

Отдельно следует отметить следующие библиотеки:

  • InfernoJS — очень похож на React.js, может использовать JSX, но дает экстремальную скорость работы, когда это необходимо.
  • Preact — клон React.js для веба, имеющий размер бандла всего лишь 3 КБ (!), реализует основной API React.

На них вполне можно строить адекватный front-end, но поддержка комьюнити не будет такой сильной.

Добавлю, что развитие SPA породило другую проблему: у краулера Google при индексации сайтов, возможно, не получится нормально проиндексировать сайт, который строится динамически, либо же нам нужна повышенная производительность. Для этого используют Server Side Rendering (SSR), но это тема для отдельной статьи.

Имплементация аспектов — лучшие практики и паттерны

После того как вы решили, какой фреймворк будете изучать, реализуйте на нем базовые вещи:

  • Стандартные вещи вроде роутинга/разбиения на модули.
  • Авторизация и аутентификация.
  • Формы, валидация форм.
  • Всплывающие окна.
  • Загрузка файлов.
  • Дебаунсинг ввода и событий.
  • Асинхронность приложения.
  • Производительность нагруженных страниц.

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

Верстка

Это одна из главных тем в front-end-разработке. За последние 10-15 лет верстка очень сильно продвинулась благодаря новым возможностям браузеров. То, что надо понимать прежде всего, — это базовые HTML4/CSS2, далее на их основе HTML5/CSS3 — с новыми тегами, Flexgrid, переменными, CSS-свойствами, помогающими решать более сложные задачи более просто. Далее — CSS-препроцессоры вроде SCSS, LESS, Stylus, PostCSS. Они помогают избегать дублирования CSS-кода, вводить переменные, добавлять примеси и еще много всего — лучше почитать тут.

Более продвинутый уровень:

  • Адаптивность и кросс-браузерность.
  • Методологии верстки типа БЭМ.
  • Основы SEO и как правильно разрабатывать веб-страницу для корректной индексации поисковыми движками.

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

UI kits/libs

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

CSS-фреймворки

Позволяют решить самые частые проблемы в верстке и сделать ее максимально быстрой и правильной с точки зрения пропорций, валидности, адаптивности и кросс-браузерности: Bootstrap, Bulma. Если поискать, существует много WYSIWYG-конструкторов для Bootstrap.

Паки UI-компонентов

Каждый год выходят новые версии и паки, достаточно просто найти информацию о них в интернете в похожих статьях по запросам вроде Best React UI Component Libraries. Например, Material реализован для Angular и других фреймворков/библиотек.

UI-библиотеки

Обычно платные, более продвинутый уровень UI-компонентов. Имеют интеграцию друг с другом и решают практически все возможные задачи промышленной разработки, интегрированы с самыми популярными front-end фреймворками: DevExtreme, KendoUI, ExtJs.

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

Заключение

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

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

LinkedIn

Лучшие комментарии пропустить

Понимание клиент-серверной и сетевой архитектуры

Я прошу прощения, а как бекенд разарботчик может этого не понимать?

Интересная статья, спасибо
Сам backend’ер, с уважением отношусь к серьезным full’ам.
Такой хаос в голове вместить — это достойно уважения.

167 комментариев

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

Тотальный зоопарк, но судя по всему с этим ничего не поделать. Провел в свое время на фронтенде 5 лет, смигрировал в бекенд и глядя на все это возвращаться не сильно хочется. В догонку к отличной статье и вопросам на тему кто же должен писать TDD, а кто заниматься версткой советую прочитать вот это:
css-tricks.com/the-great-divide

Angular + Java — идеальное сочетание для full-stack веб-девелопера

MobX это прямой конкурент Redux и, наверное, VueX — средство для создания
централизованных хранилищ. Причём в классическом ООП стиле, что большинству бэкендеров должно быть понятней.

у меня одного ощущение, что некогда прекрасный мир дотнета (VS+Resharper) незаметно оказался в руках злодеев линуксоидов — сначала дотнетчикам начали насаждать гит, который многие переварили лишь при помощи черепашки, отбивались от гита ТФСом как могли, но таки сдали позиции. Дальше нам подбросили .net core и пошло поехало зоопарк инфраструктуры фронтэнда и контрольный в голову — докер. Не знаю что там глобальный заговор Ротшильдов против человечества, но на лицо заговор линуксоидов и любителей командной строки.

Фуллстек це круто. Всі в фуллстеки! Хто топить проти фуллстеків тому треба докупити модуль пам’яті як Джоні Мнемоніку і все буде ок. Якщо ви девелопер з 5+ роками досвіду то фуллстечити на jQuery ізі можна навчитися за півроку, аби був реальний проект. А далі реакт шмеакт вивчити і ціни вам не буде. Вся ця ботва легко дається коли вже толково шариш як sql в json-чики переганяти і рест ендпоїнти писати.

Ось тільки не зовсім зрозуміло нашо зі старту вчити всю сучасну фронтенд кухню якщо можна спокійсно фуллстечити на rails/laravel/django/phoenix/asp.net

Ні, воно звичайно корисно знати реакт, але для того шоб фігачити прості штуки краще знати HTML. Хоча коли справа доходить до серйозних штук то тілібонькання дом дерева вручну вже не вставляє — хочеться норм речі писати.

Анекдот як як став фуллстек макакою: t.me/full_of_hatred/98

От тут нижче пишуть шо типу фуллстек фуллстеком а все одно будеш гірше ніж топ фронтенд батрак.

Можливо.

Але питання в тому шо ти на своїх скілах ізі витягнеш 80% проекту, а з 20% едж кейсів (галіма верстка, нюанси орієнтації екрану і тд) хай трахається той самий топ фронтендер. А якщо ти робиш б2б продукт то бізнесу часто можна поясниити щоб відкривали твій вебшит тільки в хроміумі і не балувалися шиндовс ХР. Короче кажучи якщо ви не креативне дігітал агенство вінтаж де сайтики з анімаціями та іншим вебшитом, то все буде ок.

Бути норм бекендером + посереднім фронтендером — це вже топ, як мінімум буде більше порозуміння з рештками команди і більше емпатії коли тіпи кажуть тобі шоб ти переписав два ендпоїнти в один і змінив формат даних бо їм так зручніше малювати формочки.

Далі залишилося ше навчитися це все деплоїти в амазон (шо теж нескладно) і можна собі навішувати ярлик девопса — цікаво як такий вид обізян називається? ТТТ-шейпед макаки! (бекенд, фронтенд, (дев)опс).

Тут я з Юрою погоджуся шо багатьом бекенд тіпам не вистчає девопс/sre скілів. Не кожен може навіть засшшитися на інстанс тільки деякі можуть. І це реально харить бо там вмінь кіт наплакав, але люди все одно хочуть сегрегуватися і сидіти у своїх пісочницях.

Ось тільки не зовсім зрозуміло нашо зі старту вчити всю сучасну фронтенд кухню якщо можна спокійсно фуллстечити на rails/laravel/django/phoenix/asp.net

Вы имеете ввиду полностраничные обновления ? Если да — то нельзя.

Але питання в тому шо ти на своїх скілах ізі витягнеш 80% проекту, а з 20% едж кейсів (галіма верстка, нюанси орієнтації екрану і тд) хай трахається той самий топ фронтендер.

Front-end разработчики не занимаются версткой. Ею занимаются другие люди.

Бути норм бекендером + посереднім фронтендером — це вже топ, як мінімум буде більше порозуміння з рештками команди і більше емпатії коли тіпи кажуть тобі шоб ти переписав два ендпоїнти в один і змінив формат даних бо їм так зручніше малювати формочки.

Это выгодно, всем.

Далі залишилося ше навчитися це все деплоїти в амазон (шо теж нескладно) і можна собі навішувати ярлик девопса — цікаво як такий вид обізян називається? ТТТ-шейпед макаки! (бекенд, фронтенд, (дев)опс).

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

Вы имеете ввиду полностраничные обновления ? Если да — то нельзя.

wat?

Не поняв шо ви хотіли сказати. Для rails є турболінкс (який між іншим досі більш менш норм працює), для phoenix liveview у інших теж є свої прибулуди які дозволяють перерендерити шматок сторінки а не всю.

Front-end разработчики не занимаются версткой. Ею занимаются другие люди.

топ кек. Ви напевне з тих людей шо ділять абізян на «кодерів», «девелоперів» та «інженерів»?

ДевОпс это не кто деплоит, а кто инфраструктуру деплоя настраивает.

Повар це не той хто готує, це той хто список продуктів складає.

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

Не бачу зміста навчатися фронтенду, т.к. є люди які зроблять це краще.

Сучасний стан справ в інфрі — такий самий як і в фронті. Якщо раніше треба було вручну ходити на сервера і збирати пакети або іншу діч то зараз наворотили купу рівнів абстракції докери шмокери оркестратори, вагон рішень від вендорів так шо зовісм не обов’язково вміти налаштовувати хапроксі для лоад баланса. Можна дві кніпочки в інтерфейсі амазону або гцп ткнути і отримати те шо хочеш.

Не поняв шо ви хотіли сказати. Для rails є турболінкс (який між іншим досі більш менш норм працює), для phoenix liveview у інших теж є свої прибулуди які дозволяють перерендерити шматок сторінки а не всю.

а, типа Microsoft Ajax/Update Panels, я работал с такими подходами — дичайший вид извращения, который сыпится на уже +/- сложной логике.

топ кек. Ви напевне з тих людей шо ділять абізян на «кодерів», «девелоперів» та «інженерів»?

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

Не бачу зміста навчатися фронтенду, т.к. є люди які зроблять це краще.

Инфраструктура настраивается 1 раз, фронт-енд пишется неразрывно,
Я описал кейсы когда это уместно, вы читали начало ?

. Можна дві кніпочки в інтерфейсі амазону або гцп ткнути і отримати те шо хочеш.

Да, я деплоил на амазоне, согласен, ничего сложного.

Microsoft Ajax/Update Panels,
Microsoft

сорта говна.

в Rails наприклад воно працює само, досить непогано з коробки, і не треба нічого окремо налаштовувати. Для 80% цього вистачає, для 20% — можна або сторінку перезавантажити або дом дерево покрутити вручну.

Втім, для дійсно складних апплікейшенів реакти звісно краще підходять.

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

це ті самі верхні 20% для яких тримається один верстала. інших 80% можу (та повинен) і я зробити.

Инфраструктура настраивается 1 раз

топ кек

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

Я не считаю bootstrap’инг полноценной версткой.

Конкретно зараз я про бутстрап не писав.
Більш менш ок верстка це не якась магія.

Парадокс — я начинал путь в айти с верстки, но верстаю я хуже всего )

це реально, але напряжно. якщо довгий час якісно педалити і фронтенд нормальний і бекенд, вимотуєшся дуже швидко. але на роботу беруть аж бігом, це плюс ) і як розвиток в ширину теж цікаво

По моему скромному мнению, Full-Stack — это больше о том как девелоперу выжать больше бабла, не более того ) Или о понторезах, которым по кайфу гордо заявлять — та я Full-Stack, пасть порву, моргало выколю ! :)))
Как показывает практика одновременно быть хорошим Back-End & Front-End девелопером очень не просто, почти на грани возможного, именно хорошим. По крайней мере так было до HTML5, возможно сейчас ситуация изменилась и все браузеры стали поддерживать единые стандарты, или есть какие-то вменяемые фреймворки которые невилируют эти различия. Но всмоминая до HTML5 эру, работа фронт энда в основном сосотояла, в том, что бы как-то обложить это всё костылями и заставить работать в различных браузерах, в применении различных триков, каких-то воркераундах и т.д. и т.п. Т.е. это постоянно нужно было тестить код под разными браузерами, пробовать побороть очередную кривизну и отклонение от тандаров IE и т.д. Сайты типа: www.quirksmode.org были как настольная книга.
Соответственно это отнимало большую часть времени, и при этом следить ещё за обновлением SQL Server, выходом новых фич в очередном Back-End Framework и т.д. не получалось чисто физически, из-за нехватки времени. Поэтому лично мне пришлось в какой-то момент сделать выбор, определиться со специализацией и двигаться в этом направлении, посвящать этому большую часть времени, что бы достичь какой-то глубины, хотя бы в чём-то одном, нежели распыляться на множетсво технологий (которых к слову в Front-End, становится всё больше и больше).
Да, на готовую разметку и уже устоявшиеся подходы, добавлять новый функционал — не проблема. Но вот если поехала разметка или при перевороте девайса на 90 градусов всё поломалось ИМХО нужно дать это профессионалу, который следит за последними событиями из мира Front-End, знает всё ньюансы (которых не мало). Если конечно мы говорим о реальном проекте, с ограниченными ресурсами. Если конечно есть неприлично много времени, то да, можно во всём разобраться, но как показывает практика, на реальных проектах, гораздо более эффективнее, разделение на Back-End & Front-End, вместо Full-Stack.

это больше о том как девелоперу выжать больше бабла, не более того )

Потому что клиент — наивный человек, и ему проще поверить в магию чем как-то вовлекаться и/или руководить.

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

Соответственно это отнимало большую часть времени

Это ж сколько было отожрано времени что у вас quirksmode — настольная книга, а про caniuse не слышали ?..

Мелкомягкие адепты слишком часто и слишком быстро застревают во времени и пространстве, ну это не удивительно для платформы где есть лишь один нормалный OpenSource’ный MVC фреймворк :D

caniuse

- не слышал, думаю лет 8-10 назад, когда я имел отношение к Front-End его не было, ибо знал бы наверняка.

Бывает.

В телеге есть достаточно много хороших сообществ.

Есть хотя бы местный beerjs и frontend ua

Спасибо за инфо, но я пока не планирую профессионально заниматься Front-End, возможно в будущем пригодиться.

Там хорошие сообщества, стоит вливаться даже если дела особо с фронтом не имеете.

Вот это реально полезная вещь, спасибо за наводку.
Я бы добавил в статью еще список полезных сообществ.

О, ну какраз примерно в то время, даже чуть раньше я соскочил с Front-End :)

Юрий, Ваш комментарий отдает токсичным отношением, и невежнством, объясню почему:
— Возможно речь идет о времени, когда Caniuse еще не вышел, в самый расцвет jquery, в доангулярное время.
— Nancy имеет узкую сферу применения и не удобен для решения большинства задач бизнеса.
— Имейте уважение к людям, с которыми общаетесь, вроде взрослый человек, а пишите как школьник.

... решения большинства задач бизнеса

Не стоит судить по себе.

Имейте уважение к людям

Имею.

Мелкомягкие адепты слишком часто и слишком быстро застревают во времени и пространстве, ну это не удивительно для платформы где есть лишь один нормалный OpenSource’ный MVC фреймворк :D

Ну тут главно не количество, а качество... Один качественный, ИМХО много лучше чем куча недоделанного барахла :)

Тут надо понимать что MS не может угнаться за остальным миром — существует довольно большое количество жизнеспособных OpenSource сообществ, там люди приходят к очень хорошим и качественным решениям, быстро их реализуют и проверяют на практике...

Понятное дело что «недоделаного барахла» очень много, но там где есть жизнеспособное сообщество — ему просто нет места. Если сравнивать уровень QA, даже банальный Code Coverage, то рисков и проблем в подобных OpenSource проектах действительно не много. Чего не скажешь, например, про тот же TypeScript ...

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

MS никогда полноценно не инвестировал и не строил OpenSource сообщества.

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

Та ладно в Open Source баги по 3 года лежат, аж диву даёшся. А в firefox один про textarea лет 12 лежал.

В OOS есть своя динамика сообщества и свои приоритеты, согласно текущему CashFlow, — надо их понимать и закладывать в риски.

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

Как я написал, мне пришлось сделать выбор в сторону бек енд, ибо на тот момент было сложно одновременно усидеть на двух стульях. И да, с тех пор мои знания устарели, собственно спасибо Владу за обзор, немного освежил своё представление о сегодняшней Front-End разработке. Только причём тут мелокмягкие, на тот момент никто не мог предложить нормального решения и дело было не в Майкрософте, а в том что сами методики Front-End были достаточно не зрелыми, для создание сложный веб-приложений, и требовали больших трудозатрат...

Только причём тут мелокмягкие, на тот момент никто не мог предложить нормального решения

Его до сих пор нет, но даже до того что есть они не дотягивают...

а в том что сами методики Front-End были достаточно не зрелыми

В 2009ом можно было и второй SproutCore нормально использовать, другое дело что о нём мало кто знал...

и требовали больших трудозатрат...

До сих пор трудозатраты просто непомерны и неоправданны.

... а кто-то формально верифицируемые полиедральные компиляторы с таргетами в WASM+JS пишет, чтобы хоть как-то решить этот вопрос %)

Привет Ростик, рад что ты зашел почитать :)
Есть несколько оговорок,
— Сорвменная экосистема front-end разработки построенна таким образом, чтобы нивилировать различия между поведением браузеров, для этого есть полифиллы и транспайлеры, UI/css фреймворки и все то о чем я писал.
— Верстка это не front-end разработка, часто этим занимаются другие люди, либо используются готовые компоненты.
— Знать идеально front & back нет смысла, надо знать о существовании некоторых фичей, и по ситуации уметь их разбирать, такой подход как ты написал правильный исходя из парадигм «выжимания бабла», по сути бизнес строится вокруг максимизации прибыли и минимизации операционки.

на реальных проектах, гораздо более эффективнее, разделение на Back-End & Front-End, вместо Full-Stack.

Опять таки зависит от процесса — если идет работа по Waterfall-подобному процессу — то да, когда спека УЖЕ известна.
Если идет либо Agile, либо «под клиента», то это будет гигантский оверхед все хотелки разделять на два рода задач а потом собирать вместе.

Привет :) Спасибо в любом случае за проделанную работу. Освежил свои знания.

— Сорвменная экосистема front-end разработки построенна таким образом, чтобы нивилировать различия между поведением браузеров, для этого есть полифиллы и транспайлеры, UI/css фреймворки и все то о чем я писал.

Это они на лету колбасят или нужна компиляция и в рантайме это всё не тупит потом ?

Просто твой код процессится таким образом, что ты пишешь на «Искусственном» языке, который не имеет отношения к браузеру и имеет несуществующие фичи/объекты, а он компилируется в обычный JavaScript(ES5.1). Есть варианты с компиляцией в рантайме, вроде бы во VueJs.

Ага, т.е. впринципе сейчас уже не нужно париться о совместимости с различными браузерами получается, не теряя при этом в производительности. Это радует ! Ну если так, то да, тогда не вижу проблем в том что бы быть Full-Stack. Если у тебя готовые компоненты, ты не паришсь о совместимости, и ты не отвечаешь за разметку, то норм.

Таки да, энерпрайз пишется на готовых компонентах / CSS-фреймворках. Код пишется на типизированных языках с классами, короче уже все иначе.

По моему скромному мнению, Full-Stack — это больше о том как девелоперу выжать больше бабла, не более того )

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

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

если не 6к, то не больше, но это по харькову

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

5.5к платят, но не всем, вот 6к еще не довелось увидеть, просто шаг же +500 :)

Насколько мне известен рынок — сейчас ЗП синьеров (не тех. лидов, не тимлидов) по Киеву это потолок 4.5к. 5к это техлид/тимлид.
Харьков и 5.5к не слышал. Можно подробности в личку ?

я на звичайного девопса 5к офер отримував.
на рубі девелопера (не тімліда) теж міг 5к отримати, але по рубі скілам не дотягнув і дали 4.5к
всякі модні контори типу people.аі та рінгів наскільки мені відомо ще більше можуть платити.

Так шо потолок для сеньорів це не 5к, це вище.

Короче кажучи йдіть по собєсам і самі з’ясуйте, а то може в датаарті вам 1к недоплачують )))

Короче кажучи йдіть по собєсам і самі з’ясуйте, а то може в датаарті вам 1к недоплачують )))

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

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

Насчет Киева понял, спасибо. Возможно, не изучал вопрос глубоко.

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

Переїжджайте в київ на 6к, нашо вам той Днєпр.

Пока-что не звали на 6к :D видимо не дорос. А вообще я бы сравнивал Днепр и Киев с коррекцией в 500$, которые отожрет Киев для жизни сверху.

А ви походіть по собєсам — будете приємно здивовані.

Сейчас нет особо желания переезжать в Киев, а так спасибо за советы : — )

Хм, я честно говоря думал что больше. Но просто тут большой вопрос, кто такой Full-Stack. Это человек который знает взде по чуть чуть или это мастер во всём :)
Первому конечно нужно платить ИМХО не более чем узконаправленному синьйору, а второму больше :)

По чуть чуть. Для многих задач бизнеса этого достаточно. Когда не достаточно, тогда уже нанимают узких спецов.

Ну такое... для местных дилетантов прокатит.

В целом попытка хоть что-то систематизировать — похвальна.
Некоторые рекомендации уже успели лет 5 тому назад морально устареть, а некоторые и вовсе вредные.

Система сборки модулей и таск-раннеры

Webpack потиху уходит на задний план так как ES modules нормально работает в браузерах, для всего остального хватает gulp 4.

Там ситуация ещё интереснее обстоит из-за поддержки приоритетной загрузки на http/2 — jspm перекочевал прямо в браузеры. Ну и с QUIC’ом и Http/3 всё ещё шустрее.

Есть довольно упоротые товарищи, которые компилируют TypeScript bazel’ем, на всех машинах в офисе... потому что так быстрее.

По хорошему надо собирать browser target’ед build’ы через babel-preset-env и postcss-preset-env, так как от браузера до браузера размер бандлов и файликов может отличаться. Такое отлично обслуживается через CloudFlare Workers. Пользователи не должны страдать потому что кто-то пользуется Edge’ем или IE ...

TypeScript

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

TypeScritpt и FlowType уже сейчас нормально компилируется babel’ем.

Для FP TypeScript не особо подходит.

FP достаточно знать на уровне lodash-fp, что бы было понимание чем отличается _.chain от _.flow, и какие преимущества трансдьюсеров.

Unit/UI-тесты
чаще тесты пишут профильные front-end разработчики

Так как в Украине QA приравнивается к стаду мануальных тестировщиков тыкающих в десятка три браузеров/мобильных устройств, и с какой-то вероятностью они может быть отловят «тот самый» баг перед релизом.

Ну и reproducible state’a с нормальными Ops’ами и логированием тоже нету... банально подключить Sentry и reproduce’нуть State — непосильный труд.

TDD не практикуют... Потому что долбо*бы

Ну не удивительно что Вы советуете морально устаревшие решения.

Как минимум jasmine/mocha уже можно сливать в помойку.

Стоит пробовать Ava, Webdriver.io.

Вот чего действительно не хватает существующим бэкендерам и хвалённому «fullstack’у» так это навыков работы с СУБД и DevOps’aми/SRE.

Стоит как минимум разобраться во всём HashiCorp стэке.

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

Обычно, нет понимания сопутствующих долгосрочных рисков, а в «мелких проектах», куда этих самых «jack of all the trades and the master of none» ищут, не надо рефакторить и за качеством следить, там надо фичи быстрее разрабатывать...

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

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

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

А я полагал, что для этого есть специально обученные DBA. А интернет-кабель фуллстек дев не должен в кабинет себе прокладывать? :)

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

есть специально обученные DBA

В местных аутсорсах ?

Не знаю, не видел... видел архитектов с утверждениями «это ж ещё SQL надо знать».

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

Нет, просто не умеют в SQL... и понятия не имеют о рисках долгосрочной эксплуатации современных СУБД.

Писать логику в SQL себе же хуже.
Это неподдерживаемый код, с которым могут разобраться либо бекендеры которым интересно либо DBD.
— не структурируется
— дублирование приветствуется, любое его структурирование влечет падение производительности
furdak.net/...​nie-koda-v-ms-sql-server вот я описывал случаи когда это уместно с моей точки зрения.

Это неподдерживаемый код

Были EPR’ки 20ти летней давности на plSQL’e, с нормальным Code Coverage и тестами, отваливалось раз в 2-3 года и починить особо не составляло проблем... в T-SQL — может быть.

С логики в базе была вся валидация сущностей и авторизация в рамках простого RBAC’a.

Были примеры когда весь ААА запихивали в базу — с разной степенью успешности... но особенно весело обстоят дела с GraphQL / REST мапперами, так как там в аккаунтинге и авторизации часто нужен полноценный ABAC с кастомными DSL’ками.

любое его структурирование

Ну там фичи PostgreSQL’я или даже MySQL’я существующие ORM’ы не покрывают даже отчасти. По этому утверждать что «Писать логику в SQL себе же хуже» не совсем корректно — зависит от самой СУБД и сопутствующей экосистемы, да у MSSQL с этим есть определённые проблемы и очень большой недостаток функционала.

влечет падение производительности

Не знаю... до 15Тб рабочей базы использую почти одни и те же дизайны.

Надо уметь хотя бы в контролируемую денормализацию, и хотя бы понимать no-offset.

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

Мне жаль что в мозгах разрабов SQL == «реляционная СУБД».

15 ТБ лучше уже юзать биг-дейта подходы

Например ?

Мне жаль что в мозгах разрабов SQL == «реляционная СУБД».
SQL .... is a domain-specific language used in programming and designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS)

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

Но это не значит, что скл для этого предназначен. Как и то, что скл (или его расширения) хорош и правилен для написания логики в базе.

чем традиционно вкладывают в скл.

У меня уровень хотя бы «просто использовать средства СУБД».

Для меня CREATE DOMAIN или CREATE RULE CREATE TABLESPACE CREATE MATERIALIZED VIEW, не являются тайной за семью печатями, потому что «ORM’ы так не умеют».

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

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

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

Simple != Easy
Complex != Hard

Надо понимать что джуну достаточно просто прочитать 2 страницы документации, посмотреть примеры тестов в проекте и попробовать что-то поправить.

есть отсутствие овер-инженеринга

Овер-инжениринг подразумевает огород хранимок и прочих поделок непонятно зачем... я же просто предлагаю ознакомиться и использовать весь функционал СУБД для снижение бизнес рисков и сложности реализации бекенда.

не являются тайной за семью печатями, потому что "ORM’ы так не умеют".

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

Гляньте GraphQL мапперы типа prisma, возможно Ваше мнение немного изменится.

Посмотрел.
По идеологии — это ОРМ. По функционалу — полный примитив.

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

Какую ?

Не умеют возвращать объекты классов. И только эту задачу и призваны решать ОРМ.

Звучит как сюжет нового хоррора от Кинга. :)

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

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

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

Блокирующие операции, с побочкой, принципиально в хранимках лучше не делать, особенно если у СУБД нет возможности нормально отлавливать исключения... в целом ситуация, действительно, абсурдная.

В местных аутсорсах ?
DBA
аутсорсах

Ааа. Ну да. Да.

Ciklum — не умеет.
Soft Serve — не умеет.
Luxoft — не умеет.
Global Logic — не умеет.
Cogniance — не умеет.

У вас есть пример на уме, если не секрет конечно ?
И о какой конкретно СУБД идёт речь ?

Ааа. Ну да. Да.

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

Ок, мне текст сложно эмоции передает.

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

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

Это как

— Давайте обучать наших сотрудников ?
— А если они уйдут ?
— А если остануться ?

Вот, к сожалению, у нас только «остаются»...

У нас есть DBA/DBD специалисты. Я думаю в других компаниях есть тоже по необходимости. Но мне приходилось иногда делать их работу в том числе.

Luxoft точно умеет. В нем на куча проектов есть отдельные позиции DBD and DB architect. И на этих позициях есть более, чем вменяемые специалисты. По мне так для аутсафинга (оплата за тело) вопрос вменяемости специалистов более относится к заказчику (60-80%)

В контролируемую денормализацию и в банальное профилирование с FlameGraph’aми, к сожалению, не умеют.

для местных дилетантов прокатит

Буду рад услышать список рекоммендаций для роста как FE developer, но то о чем дальше Вы пишете не совсем стыкуется с моим пониманием.

Webpack потиху уходит на задний план так как ES modules нормально работает в браузерах, для всего остального хватает gulp 4.

Не согласен, Angular CLI имеет под капотом тот же WebPack, и для экосистемы это де-факто стандарт, кучу куда написано. Никто за 1 день его не выкинет.

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

Не согласен, TypeScript используется по дефолту в Angular.

Для FP TypeScript не особо подходит.

А он и не должен, для этого выбирают ELM.

Как минимум jasmine/mocha уже можно сливать в помойку.

Не согласен, сейчас написано очень много кода именно на этих фреймворках, опять таки за день или при выходе нового этот код никто не выкинет.

Стоит пробовать Ava, Webdriver.io.

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

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

Я это все понимаю, и рекуррентные запросы писал, и оконные функции использовал, и профилированием занимался, и даже игры писал на SQL(github.com/...​dislavFurdak/SQLSnakeGame) но я не поинмаю в контексте этой статьи причем тут это :) ? В 90% случаев для разработки корпоративного софта это не нужно. А вот уметь писать быстро фронт и еще быстрей его менять — более востребованный навык. Для других вещей нужен DBD/DBA.

Стоит как минимум разобраться во всём HashiCorp стэке.

Опять таки, пускай в этом DevOps’ы разбираются.

Обычно, нет понимания сопутствующих долгосрочных рисков, а в «мелких проектах», куда этих самых «jack of all the trades and the master of none» ищут, не надо рефакторить и за качеством следить, там надо фичи быстрее разрабатывать... менеджмент слишком бездарный чтобы как либо контролировать риски и управлять циклом разработки и внедрения — управлять достаточной эффективностью для целевой стадии развития решения.

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

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

Любой хороший разработчик на 30% архитектор, на 30% менеджер/аналитик и на 30% разработчик. Время кодеров, работающих чисто по ТЗ ушло, сейчас все более динамично.

Вы пишете не совсем стыкуется с моим пониманием.

Оно и не должно стыковаться...

потом не проблема переписать систему

У Вас на проекте что-то серьёзно переписали ? или очередной менеджер гонит палкой баги править и фичи завозить потому что «наобещали» или «клиент сказал» ?

Надо понимать что у нас нет выработанной культуры разработки и менеджмента — никто не готов инвестировать в персонал и рынок пестрит дилетантами (обратная сторона повсеместного «грибного менеджмента»).

Вы слишком часто упоминаете «о том что уже написано» у вас... не стоит судить по ситуации в своих проектах, так как чаще всего украинские проекты — помойка.

Я не думаю что у вас проект с нормальным Delivery Cycle — где нет по 50-60 issues’ов на bugfix’ы «потому что бизнес», а вы спокойно можете за сутки выкатить 2-3 фичи и раз в неделю релизнуться, получить конструктивный фидбек от целевой аудитории, а не от «чувства клиента», и принять обоснованное решение.

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

Время кодеров, работающих чисто по ТЗ ушло, сейчас все более динамично.

Согласен.

Не думаю что у Вас достаточно опыта чтобы просто понять мой подход и разделить мои ценности.

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

Нет проблем.

Ложка мёда в бочке дёгтя.

Какое-то время назад была поулярна разработка на C++ для десктоп. Потом появился C#, люди стали критиковать C++ за неудобство и перешли на C# для WinForms. Затем придумали asp.net web forms, это стало революцией и люди начали критиковать WinForms, переходя в браузер. Затем появилось MVC и люди стали критиковать WebForms, переходя на MVC, и так далее..

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

Какая нафиг разница на чем писать? Если по выделенному бюджету создается решение под клиента которое решает его проблемы. Вы оцениваете категориями гавно/не гавно, но дальше вашего субъективного эмоционального отношения эта оценка не выходит. На новые технологии люди переходят не из-за моды и не из-за желание попробовать что-то новое. Исключительно чтобы снизить косты, и ускорить разработку. Вопрос конкурренции между вендорами, не более. Конечному клиенту пофиг на чем оно сделано.

Главное — это что решение, созданное на этих технологиях поможет автоматизировать клиенту/пользователям и как дорого будет это стоить.

Если первый и второй пункт закрывается = успех.

Вы оцениваете категориями гавно/не гавно

Замечательный пример психологической проекции.

На самом деле нет, именно такими категориями я не оцениваю.

Потом появился C#, люди стали критиковать C++ за неудобство и перешли на C# для WinForms. Затем придумали asp.net web forms, это стало революцией и люди начали критиковать WinForms, переходя в браузер.

А ничё, что WinForms и WebForms возник в один день) Ладно, ок, для словца пойдёт.

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

Когда WinFormы стартанул, на большинстве машин .NET Framework не поставлялся, только с XP SP3 .NET 1.1 кажется начали ставить, до этого его приходилось тащить с приложением (30 Mb), по тем меркам не мало. И с каждым разом текущая версия .NET становилась больше, а база машин с предустановкой не поспевала.
WebForms же таких проблем не имел, а был даже местами по API похож на ASP (вот эти Server, Request, Response), его намного легче было применять для все местного использования. Конечно, доказать популярность того или другог уже не возможно.
С++ здесь вообще скорее не причём. Enterprise софт писали на Delphi и VB6, вот с них, кто-то и двигался в WinForm, а кто-то сразу в web. Почему enterprise софт начал движение в сторону web, сложно сказать? Может у большинства менеджмента были маки к 2003, и они не могли позволить писать 2 версии софта, вот и хотели cross platform. Мобилы в расчёт тогда не брали.

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

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

Не согласен, TypeScript используется по дефолту в Angular.

И это одна из ключевых причин отказаться от Angular в качестве «next great framework for our project».

Хорошо,
какой фреймворк вы предлагаете, к примеру, для приложений, требующих верифицированных средств?

Что такое

верифицированных средств

?

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

Ну или хотя бы фронтендщиков с пониманием почему «Больше 10 экшенов в Redux — это лапша...».

Можем углубиться и вспомнить поонимание типов данных в js и falsy values.

Думаю не стоит, так как обычно проще проверять каким-то lodash’eм или существующими библиотеками с проверками ESLint’ом.

Есть довольно много проектов где товарищи изучили JS по предупреждениям ESLint’a.

Вот в тот же lodash/fp действительно стоит углубиться, он и проще, и быстрее, и безопаснее той же Ramda.

Трансдьюсеры в JS сыграли очень важную роль для снижения GC pressure и увеличения доступности... надо бы в FP научиться хотя бы что бы понимать что это такое и зачем оно надо.

TypeScript
К сожалению, он имеет сейчас кучу нерешенных проблем

Т.е. под кучей вы понимаете один GitHub issue про variadic functions? :)
И именно из-за этого TypeScript рискованно использовать в новых проектах? Серьёзно?!

Нет, но это одна из текущих проблем.

На TypeScript’e много существующих решений просто невозможно типизировать, и поднятие соответствующих Adoption Rate’ов не является проблемой для MS и сообщества TS в целом.

Другое дело что Babylon нормально парсит что Flowtype, что TypeScript, и из-за проблем жизнеспособности сообщества TypeScript’a сейчас есть план по переносу функционала TSC в Babel, и TSLint’a в ESLint.

Про качество реализации Babylon’a и простоту реализации нового функционала типизированных языков — история умалчивает. Таким образом реализация и внедрение недостающего функционала, не только Variadic Functions, затягивается еще больше.

TypeScript рискованно использовать в новых проектах? Серьёзно?!

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

Я не думаю что в ваших MVP есть нормальный Definition Of Viability, и вы можете туда закладывать риски использования каких либо технологий

„Я знаю карате, кунг-фу, тэквондо и ещй много страшных слов” :)
Разумеется, риски использования технологий мы анализируем и учитываем.

На TypeScript’e много существующих решений просто невозможно типизировать

Действительно много? Удивлён. TypeScript мы используем на практике достаточно широко, и если какие-то проблемы и возникали, то только с единичными малоизвестными библиотеками, для которых никто не удосужился сделать нормальный type definition.

из-за проблем жизнеспособности сообщества TypeScript’a сейчас есть план по переносу функционала TSC в Babel, и TSLint’a в ESLint

Это разные и не связанные друг с другом вещи.

Что касается Babel:

Babel won’t perform type-checking on TypeScript code; it will only be transforming your code, and it will compile regardless of whether type errors are present. While that means Babel is free from doing things like reading .d.ts files and ensuring your types are compatible, presumably you’ll want some tool to do that, and so you’ll still need TypeScript.
Yeah, you know it’s broken. You’ve probably broken a few unit tests too. But you’re just experimenting at this point. It’s infuriating to continuously ensure all your code is type safe all the time.
This is the second advantage of Babel stripping out TypeScript code during compilation. You write code, you save, and it compiles (very quickly) without checking for type safety. Keep experimenting with your solution until you’re ready to check the code for errors. This workflow keeps you in the zone as you’re coding.

Спасибо, не надо. Это убивает саму суть использования TypeScript. Для херак-херак и в продакшен лучше уж сразу берите обычный ES6/ES2015 (и да поможет вам Бог в ловле неочевидных ошибок, вызванных несовместимостью типов). А в крупных проектах нет проблем настроить webpack для запуска „честного” tsc.

Что касается ESLint, то для прекращения дальнейшей разработки TSLint были свои прагматичные причины:

we noticed that there were a few architectural issues with the way TSLint rules operate that impacted performance. Fixing TSLint to operate more efficiently would require a different API which would break existing rules (unless an interop API was built like what wotan provides).

Meanwhile, ESLint already has the more-performant architecture we’re looking for from a linter. Additionally, different communities of users often have lint rules (e.g. rules for React Hooks or Vue) that are built for ESLint, but not TSLint.

Given this, our editor team will be focusing on leveraging ESLint rather than duplicating work.

и, как вы видите, дело здесь никак не в „жизнеспособности сообщества”, а исключительно в том, что TSLint оказался не совсем удачно спроектирован технически, и его объективно проще плавненько закопать и добавить поддержку TypeScript в ESLint.

Интересная статья, спасибо
Сам backend’ер, с уважением отношусь к серьезным full’ам.
Такой хаос в голове вместить — это достойно уважения.

к серьезным full’ам.

Не верю в их существование, так как почти никто не умеет работать с базами...

так как почти никто не умеет работать с базами...

Это болезнь вообще нашей отрасти и ее аутсортингового клейма. И многие backend’ры не могут, как ни парадоксально. Регулярно встречаюсь с точкой зрения «мне не интересно знать детали хранилища» ...

Ото для мене вчора був сюрприз коли мені знадобилося зробити alter table add column на таблиці в mariadb з мільоном записів зробити.
Міграція проводилася автоматом при старті сервера і сервер не стартував )))

Довго думав що у мене не так поки не почитав стековерфлов. В постгресі таких проблем немає.

Але такі штуки стріляють раз на рік. Для звичайної роботи досить знати основи своєї субд. ДБА-скіли мені жодного разу не знадобилися на постійній основі. Так, раз налаштувати реплікацю, раз дамп зробити, раз розгорнути. Все стековерфловиться ізі, головне не сцяти команди виконувати.

В постгресі таких проблем немає.

Є, просто DDL потрапляє в WAL і буде виконаний при наступному Vacuum’і...

Так, раз налаштувати реплікацю, раз дамп зробити, раз розгорнути.

Залежить від розміру бази, як мінімум потрібно освоїти партиціонування щоб не роздувати робочі таблички та індекси — не буде деградації швидкодії бази, та й не буде потрібне кешування другого рівня (ehcache memcached redis тощо). Реалізація значно спрощується, та ризиків значно меньше, так як замість того щоб городить свій кеш — є можливість нормально використати той що вбудований в СУБД.

Є, просто DDL потрапляє в WAL і буде виконаний при наступному Vacuum’і...

Може й так, але я про це не знаю і альтер на таблиці в десяток мільонів записів проходить моментально.

Я говорю про те що скіл DBA зараз треба дуже рідко, а якщо реально попав на едж кейс то розкуруюється мануал і все робиться.

Мануалів мало, а друкувать та читать документацію мало в кого руки доходять...

Єслі шо — я знаю, до кого звертатися )))

Та я ж тільки радий...

Є цікавий проект, пізніш відпишу, думаю тобі буде корисно.

Ну если зоопарк баз — это одно. Но одну базу — вполне реально. Конечно речь о людях 10+ лет.

Да, сам вполне комфортно живу с postgresql’ем — у него хватает недостатков, но и по функционалу довольно много преимуществ. Вообще не вижу смысла сейчас использовать MongoDB или Neo4j, но в редких случаях бывает нужны колоночные типа Cassandra / Scylla.

В целом, соглашусь. Сам, где только можно и целесообразно, агитирую за PostgreSQL.

Вместе с тем, та же Кассандра (да и, прости Господи, Монга) может оказаться лучшим выбором там, где нужно вливать в базу много данных быстро.

Можно, конечно, ставить «проставки» в виде Kafka, но их тоже ещё нужно уметь готовить.

Кстати, по PostgreSQL, слышал он не хуже MS SQL Server, но в нем нет многих фич, что есть в MS SQL.
Но в .NET работать с postgreeSQL сложней, и не всегда возможно мигрировать готовый солюшн с MS SQL Server на PostgreSQL, из-за отсутствия поддержки MARS
github.com/...​FrameworkCore/issues/1665
github.com/npgsql/npgsql/issues/462
forums.devart.com/viewtopic.php?t=33074

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

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

Спасибо за систематизацию и огромный труд. Я бы еще добавил в статью знания связанные с Docker и хотя бы базовое понимание настройки сереров. Хотя, возможно не всем FullStack разработчикам оно надо, но на фрилансе оно востребовано.

Работая в энтепрайзе скажу честно — ни разу не использовал докер. Где-то это было бы уместно, где-то нет, но и так все работает)) За день настроил ENV локально и все. Докер удобен если нужно масштабироваться между многими энвами клиентов.

Это просто .NET Core не добрался до Enterprise на 100%. А Docker на Windows Container, еще в зачаточном. Так бы намного больше использовали.

Я пишу на .NET core в энтерпрайзе сейчас. У нас нет сотен окружений, деплойментом и вопросами связанными с ним в большой компании-клиента занимается вообще отдельный отдел девопсов.

Спасибо :-)
Если честно, я в какой-то момент махнул рукой на весь этот зоопарк и закрылся в уютном бэкенд-мирке, но пора оттуда вылазить...
Раньше имел коммерческий опыт с AngularJS, но сейчас думаю заняться React.

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

но почти во всех проектах я занимался также и front-end частью.

У вас, видимо, ухудшение качества проекта имеет меньшую важность стоимости разработки.

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

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

Статья хорошая... но лучше останусь я баристой-любителем, чем буду осваивать этот мгновенно устаревающий фронт... хотя до d3.js руки рано или поздно дойдут

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

FYI,
Вы упомянули про русскоязычную документацию для Vue.js, с недавних пор React.js тоже имеет локализированную документацию:
ru.reactjs.org
:)

Правильное название JavaScript — ECMAScript (ES), JS — это маркетинговое название.

JavaScript — нифига не просто маркетинговое название. Что за чушь? Это полноценный язык, который базируется на ECMA стандартах.

JavaScript был языком до стандартизации, но после стандартизации ассоциацией ECMA (ECMA-262) он начал называться ECMAScript.

Из-за проблем с торговой маркой ECMA не могла использовать JavaScript в качестве названия. После непродолжительных дебатов было решено, что описанный стандартом язык программирования будет назван ECMAScript. На сегодняшний день JavaScript это всего лишь коммерческое название ECMAScript.

Мда... Для меня он навсегда останется JS

JavaScript — можно воспринимать как обобщенное название семейства диалектов, habr.com/...​y/livetyping/blog/324196 тут хороший перевод статьи как раз про стандарты и его разработку.

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

Статья хорошая, читается на одном дыхании. Отлично структурирована.

Хотел бы поделиться с вами мыслями удивительного человека:

...don’t just believe that because something is trendy, that it’s good. I’d probably go the other extreme where if something, if I find too many people adopting a certain idea I’d probably think it’s wrong or if, you know, if my work had become too popular I’d probably think I’d have to change.

That’s of course ridiculous but I see the other side of it too often where people will do something against their own gut instincts because they think the community wants them to do it that way, so people will work on a certain subject even though they aren’t terribly interested in it because they think that they’ll get more prestige by working on it.

I think you get more prestige by doing good science than by doing popular science because if you go with what you really think is important then it’s a higher chance that it really is important in the long run and it’s the long run which has the most benefit to the world.

— Donald Knuth

Обязательно послушайте: www.youtube.com/...​EsFzeNLngr1JqyQki3wdoGrCn

Спасибо, позже послушаю классиков)

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

Остальное о рисках и количестве людей.

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

Ещё прототипировать можно гибко, быстро и сложно.

Согласен. Очень удобно когда один лид-девелопер сразу же:
— контактирует с клиентом
— реализует бизнес-логику
— реализует UI

Если вы писали на JQuery, это не совсем то, это скорее веб-мастеринг, добавляющий динамику страницам.

Какое-то злое обобщение. Даже AngularJS внутри имеет интеграцию с jQuery. Тоесть когда ты используешь AngularJS + jQuery (ты веб-мастерёнок), «без» ты уже нинзя. SPA писали за 10 лет до появления всяких фреймворков, использовали всякое — включая jQuery.

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

Я сейчас обосную.
Я лично видел множество систем, написанных на JQuery, с очень-очень сложным UI, саппортить такое нереально. Если ты хочешь использовать DOM через Реакт или Angular — везде есть обвертки типа refs, какой смысл вообще в JQuery. AngularJs я не считаю современной технологией.

А підтримка дуже-дуже складного UI на Angular раптом стане простіша?

да,
— модульность
— компонентность
— разделение отображения и логики
— тестируемость
— синхронизация
На Angular есть разные UI-пакеты, типа DevExtreme, в которых уже почти все реализовано что вам нужно от сложного UI.
Поправьте если не согласны.

Ну ти хто пишуть дуже складні на jquery or something else теж мають свої улюблені компоненти і вони теж працюють :)

Що ви завтра будете робити, якщо google опублікує новий фреймворк AngularJS++ — ще краще, а старий angular закинуть — як ви його будете підтримувати через 10 років? так само як і jquery :)

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

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

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

Вы же CTO, ваша работа по сути думать о том, о чем я пишу :)

А как Вам datasrc система дата-байндинга существовавшая еще в IE6, 100 лет как забытая

msdn.microsoft.com/...​n-us/ie/ms533709(v=vs.94

Да, до фреймворков frontendа не было)

Отличная система, наверное.
А как вам джава апплеты и ActiveX или Flash ? :)
но мой посыл в другом, как использовать опыт лет, и не повторять ошибок, используя на первый взгляд простой подход, который обернется катастрофой.

К сожалению, ничего близкого к Flash так и не родилось. Сравнивать его с HTML5, это как Photoshop и Paint.

Я делал на Flash игры в свободное от уроков время.
Там в разы проще чем HTML5 ))

Меня одного бесит, что после Java в Javascript нет нормального autocompletion, а с Typescript с ReactJS так себе дружит?

Если речь об автокомплите — то это легко решается любыми плагинами.
Писать на TS для реката можно, но смысла мало.

А можно пример плагина для нормального autocompletion?

В Visual Studio из коробки работает. Они по сути парсят все js встроенным ts компилятором, так как любой js — это валидный ts.

просто надо затратить время на описание структуры, то, что в Java является обязательным.
TypeScript, Flow, React’s PropTypes или даже JSDoc

В WebStorm есть отличный autocomplete для Angular(TypeScript)

Понимание клиент-серверной и сетевой архитектуры

Я прошу прощения, а как бекенд разарботчик может этого не понимать?

Да просто, да, запутанно звучит, но понимать можно слишком обзорно, но да, Вы правы слишком упросил, имел ввиду скорей просто разработчиков, уже с опытом.

Например, такие случаи
— Человек, хорошо знающий базы, кое-как делающий бекенд и вообще не понимающий фронта.
— Человек, который просто пишет REST Api, и отлично знает бек.
— Человек работающий с технологиями типа WebForms/WPF,
— Начинающие разработчики, которые слабо понимают сетевую механику, но кое-что понимают в протоколе HTTP.

Да, у меня сложилось впечатление, что рисунок просто взяли с фронт-енда.

Как правило понимают чем нет. Но это не обязательно. Например бывают серверы на MQ архитектуре , где разработчик не соприкасается с http и tcp. И если ты попал на такой проект как нуб, то эти знания как там что работает на низком уровне, не появятся

ну есть же разработчики, путающие треды и асинк коллы

Подписаться на комментарии