Объясняем современный JavaScript динозавру +168




Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:


Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости


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


Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.


Олдскульное использование JavaScript


Давайте сделаем «олдскульный» сайт, используя только HTML и JavaScript. В этом случае придётся вручную скачивать и связывать файлы. Вот простой index.html, ссылающийся на JavaScript-файл:


<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JavaScript Example</title>
  <script src="index.js"></script>
</head>
<body>
  <h1>Hello from HTML!</h1>
</body>
</html>

Строка <script src="index.js"></script> ссылается на JavaScript-файл index.js, находящийся в той же директории:


// index.js
console.log("Hello from JavaScript!");

Больше для создания сайта ничего не нужно! Допустим, вы хотите добавить стороннюю библиотеку moment.js (меняет формат дат для удобочитаемости). Можно, к примеру, использовать в JS функцию moment:


moment().startOf('day').fromNow();        // 20 часов назад

Но так вы всего лишь добавили moment.js на свой сайт! На главной странице moment.js приведены инструкции:



Мда, в разделе «Установка» много всего написано. Но пока это проигнорируем, потому что можно добавить moment.js на сайт, скачав файл moment.min.js в ту же директорию и включив его в наш файл index.html.


<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Example</title>
  <link rel="stylesheet" href="index.css">
  <script src="moment.min.js"></script>
  <script src="index.js"></script>
</head>
<body>
  <h1>Hello from HTML!</h1>
</body>
</html>

Обратите внимание, что moment.min.js загружается до index.js, поэтому в index.js вы можете использовать функцию moment:


// index.js
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());

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


Использование диспетчера пакетов из JavaScript (npm)


Примерно с 2010-го развиваются несколько конкурирующих диспетчеров пакетов, помогающих автоматизировать скачивание и обновление библиотек из центрального репозитория. Bower был самым популярным в 2013-м, но к 2015-му уступил пальму первенства npm. Надо сказать, что с конца 2016-го yarn широко используется в качестве альтернативы интерфейсу npm, но под капотом он всё ещё работает с npm-пакетами.


Изначально npm создавался как диспетчер пакетов специально для node.js, среды исполнения JavaScript, предназначенной для серверов, а не фронтенда. Так что довольно странно применять его в качестве диспетчера пакетов для библиотек, запускаемых в браузерах.


Примечание: обычно диспетчеры пакетов подразумевают использование командной строки, что раньше никогда не требовалось при разработке фронтенда. Если вы никогда с ней не работали, то для начала можете почитать это руководство. Как бы там ни было, в современном JavaScript важно уметь пользоваться командной строкой (и это также открывает двери в другие области разработки).


Давайте посмотрим, как использовать npm для автоматической установки moment.js вместо скачивания вручную. Если у вас установлен node.js, то у вас уже есть и npm, так что можете в командной строке перейти в папку с файлом index.html и ввести:


$ npm init

Вам зададут несколько вопросов (можно просто жать Enter, оставляя ответы по умолчанию), а потом сгенерируется новый файл package.json. Это конфигурационный файл, в котором npm сохраняет всю информацию о проекте. По умолчанию содержимое package.json выглядит так:


{
  "name": "your-project-name",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Для установки JS-пакета moment.js можно воспользоваться инструкциями с сайта npm, введя в командной строке:


$ npm install moment --save

Эта команда делает две вещи:


  1. Скачивает весь код из пакета moment.js в папку под названием node_modules.
  2. Автоматически модифицирует файл package.json для отслеживания moment.js в качестве проектной зависимости.

{
  "name": "modern-javascript-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "moment": "^2.19.1"
  }
}

Это полезно, когда вы станете работать над проектом совместно с другими разработчиками: вместо общего доступа к папке node_modules (которая может быть очень большой) достаточно открыть доступ к файлу package.json, и другие разработчики смогут автоматически устанавливать нужные пакеты с помощью команды npm install.


Теперь нам больше не нужно вручную скачивать moment.js с сайта, npm помогает скачивать и обновлять автоматически. Если посмотрим в папку node_modules, то в директории node_modules/moment/min увидим файл moment.min.js. Это означает, что в index.html можно сослаться на скачанную через npm версию moment.min.js:


<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JavaScript Example</title>
  <script src="node_modules/moment/min/moment.min.js"></script>
  <script src="index.js"></script>
</head>
<body>
  <h1>Hello from HTML!</h1>
</body>
</html>

Приятно, что теперь мы можем автоматически скачивать и обновлять наши пакеты с помощью npm и командной строки. Но теперь надо копаться в папке node_modules, чтобы узнать местонахождение каждого пакета и вручную прописать в HTML. Это довольно неудобно, так что давайте посмотрим, как можно автоматизировать этот процесс.



Использование бандлера (bundler) JavaScript-модулей (webpack)


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


Именно это мы и делали в вышеописанном примере с moment.js example?—?весь файл moment.min.js загружается в HTML, где определяется глобальная переменная moment, которая потом становится доступна любому файлу, загруженному после moment.min.js (вне зависимости от того, нужна ли она для обращения к ним).


В 2009-м был запущен проект CommonJS, в рамках которого планировалось создать спецификации внебраузерной экосистемы для JavaScript. Большая часть CommonJS была посвящена спецификациям модулей, позволявших JS импортировать и экспортировать код между файлами как во многих других языках, без обращения к глобальным переменным. Самой известной реализацией модулей CommonJS стал node.js.



Как уже говорилось, node.js — это среда исполнения JavaScript, разработанная для запуска на серверах. Вот как сначала выглядело использование node.js-модулей: вместо загрузки всего moment.min.js в скриптовом теге HTML можно было грузить JS-файл напрямую:


// index.js
var moment = require('moment');
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());

Загрузка модулей работает прекрасно, поскольку node.js — это серверный язык с доступом к файловой системе. Также ему известно расположение всех npm-модулей, поэтому вместо require('./node_modules/moment/min/moment.min.js) можно писать просто require('moment').


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


И здесь появляется бандлер (bundler). Это инструмент для сборки модулей в единые пакеты, имеющий доступ к файловой системе. Получающиеся пакеты совместимы с браузером, которому не нужен доступ к файловой системе. В нашем случае бандлер нужен для поиска всех выражений require (имеющих ошибочный, с точки зрения браузера, JS-синтаксис) и замены на настоящее содержимое каждого требуемого файла. В финале мы получаем единый JS-файл без выражений require!


Самым популярным бандлером сначала был Browserify, выпущенный в 2011 г. Он был пионером в использовании node.js-выражений require во фронтенде (это позволило npm стать самым востребованным диспетчером пакетов). К 2015-му лидером стал webpack (ему помогла популярность фронтенд-фреймворка React, использующего все возможности этого бандлера).


Давайте посмотрим, как с помощью webpack заставить работать в браузере наш пример с require('moment'). Сначала установим бандлер в проект. Сам по себе webpack — это npm-пакет, так что введём в командной строке:


$ npm install webpack --save-dev

Обратите внимание на аргумент --save-dev?—?он сохраняет бандлер как зависимость среды разработки, так что она не понадобится на production-сервере. Это отразится в файле package.json, который обновится автоматически:


{
  "name": "modern-javascript-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "moment": "^2.19.1"
  },
  "devDependencies": {
    "webpack": "^3.7.1"
  }
}

Теперь webpack установлен в качестве одного из пакетов в папке node_modules. Можно запускать его из командной строки:


$ ./node_modules/.bin/webpack index.js bundle.js

Эта команда запускает webpack вместе с файлом index.js, находит все выражения require и заменяет соответствующим кодом, чтобы получился единый выходной файл bundle.js. Это означает, что нам больше не нужно использовать в браузере файл index.js, поскольку он содержит некорректные выражения require. Вместо него мы возьмём bundle.js, что должно быть учтено в index.html:


<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JavaScript Example</title>
  <script src="bundle.js"></script>
</head>
<body>
  <h1>Hello from HTML!</h1>
</body>
</html>

Если обновите браузер, то всё будет работать, как и прежде.


Обратите внимание, что нам нужно выполнять webpack-команду при каждом изменении index.js. Это утомительно, и чем более продвинутые возможности webpack мы будем использовать (вроде генерирования схемы источников для отладки исходного кода из транспилированного), тем больше станет утомлять постоянный ввод команд. Webpack может считывать опции из конфигурационного файла webpack.config.js в корневой директории проекта:


// webpack.config.js
module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.js'
  }
};

Теперь при каждом изменении index.js можно запускать webpack такой командой:


$ ./node_modules/.bin/webpack

Больше не нужно определять опции index.js и bundle.js, потому что webpack загружает их из webpack.config.js. Так лучше, но всё равно утомительно вводить эту команду при каждом изменении кода. Надо ещё больше всё упростить.


Такой подход очень сильно повлиял на рабочий процесс. Мы уже не загружаем внешние скрипты с помощью глобальных переменных. Все новые JS-библиотеки будут добавлены в JavaScript с помощью выражений require, а не через теги <script> в HTML. Наличие единственного JS-пакета зачастую повышает производительность. А после добавления этапа сборки появилось несколько мощных возможностей, которые тоже можно использовать в процессе разработки.



Транспилирование кода ради новых возможностей языка (babel)


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


К примеру, для CSS есть Sass, Less и Stylus. Для JavaScript самым популярным транспилятором какое-то время был CoffeeScript (выпущен около 2010), а сегодня многие используют babel или TypeScript. CoffeeScript улучшает JavaScript за счёт серьёзного изменения языка?—?опциональное использование скобок, значимые отступы (whitespace) и т. д. Babel — это не новый язык, а транспилятор, который транспилирует JavaScript следующего поколения, имеющего возможности, пока недоступные во всех браузерах (ES2015 и выше), в старый и более совместимый JavaScript (ES5). Typescript — это язык, по существу аналогичный JavaScript следующего поколения, но с добавлением опциональной статичной типизации. Многие предпочитают babel, потому что он ближе к ванильному JavaScript.


Рассмотрим пример использования babel на этапе webpack-сборки. Сначала установим транспилятор (это npm-пакет) в проект:


$ npm install babel-core babel-preset-env babel-loader --save-dev

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


  • babel-core — основная часть babel;
  • babel-preset-env — пресет, определяющий, какие новые возможности JavaScript нужно транспилировать;
  • babel-loader — пакет, позволяющий babel работать с webpack.

Сконфигурируем webpack для использования babel-loader, отредактировав файл webpack.config.js:


// webpack.config.js
module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['env']
          }
        }
      }
    ]
  }
};

Синтаксис может вас запутать (к счастью, этот код не нужно часто редактировать). По сути, мы просим webpack найти все .js-файлы (за исключением лежащих в папке node_modules) и применить babel-транспилирование с помощью babel-loader и пресета babel-preset-env. Подробнее о синтаксисе конфигурирования webpack можно почитать здесь.


Всё настроено, можно использовать в нашем JavaScript возможности ES2015! Пример шаблонной строки (template string) ES2015 в файле index.js:


// index.js
var moment = require('moment');
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());
var name = "Bob", time = "today";
console.log(`Hello ${name}, how are you ${time}?`);

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


// index.js
import moment from 'moment';
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());
var name = "Bob", time = "today";
console.log(`Hello ${name}, how are you ${time}?`);

В этом примере синтаксис import мало отличается от синтаксиса require, но import гибче в более сложных ситуациях. Раз мы изменили index.js, нужно снова запустить webpack:


$ ./node_modules/.bin/webpack

Теперь обновим index.html в браузере. Когда я писал эту статью, большинство браузеров поддерживали все возможности ES2015, так что трудно сказать, заслуга ли это babel. Можете протестировать в старых браузерах вроде IE9 или поискать в bundle.js строку транспилированного кода:


// bundle.js
// ...
console.log('Hello ' + name + ', how are you ' + time + '?');
// ...

Здесь babel транспилировал шаблонную строку ES2015 в обычное JavaScript-объединение строк, чтобы сохранить совместимость. Наверное, не самый впечатляющий пример, но транспилирование кода — очень мощный инструмент. В JavaScript можно добавить такие впечатляющие возможности, как async/await. И хотя транспилирование иногда бывает нудным и неприятным занятием, в последние годы оно помогло сильно улучшить язык, потому что многие разработчики сегодня тестируют возможности будущего.


Мы почти закончили, но в нашем рабочем процессе ещё остались шероховатости. Ради повышения производительности нужно минифицировать получившийся после сборки бандлером файл, но это довольно простая задача. Также нужно перезапускать webpack при каждом изменении JavaScript, который быстро устаревает. Рассмотрим инструменты для решения этих проблем.


Использование средства запуска задач (task runner) (npm-скрипты)


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


В 2013-м самым популярным инструментом был Grunt, но вскоре его место занял Gulp. Оба используют плагины, играющие роль обёртки для других инструментов, которым нужна командная строка. Сегодня чаще всего применяется скриптинг, встроенный в npm, который напрямую работает с упомянутыми инструментами.


Давайте напишем npm-скрипт для упрощения работы с webpack. Для этого просто изменим package.json:


{
  "name": "modern-javascript-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack --progress -p",
    "watch": "webpack --progress --watch"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "moment": "^2.19.1"
  },
  "devDependencies": {
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.2",
    "babel-preset-env": "^1.6.1",
    "webpack": "^3.7.1"
  }
}

Здесь мы добавили два новых скрипта — build и watch. Для запуска сборочного скрипта введите команду:


$ npm run build

Команда запускает webpack (с использованием конфигурации из сделанного ранее webpack.config.js) с опцией --progress, которая включает отображение прогресса в процентах, и с опцией -p для минимизации кода. Запустим скрипт watch:


$ npm run watch

Здесь используется опция --watch для автоматического перезапуска webpack при каждом изменении JavaScript-файла, это очень удобно для разработки.


Обратите внимание, что package.json может запускать webpack без указания полного пути ./node_modules/.bin/webpack, потому что node.js знает расположение каждого npm-модуля. Удобно! Сделаем ещё удобнее, установив webpack-dev-server, отдельный простой веб-сервер с функцией горячей перезагрузки. Установим в качестве зависимости среды разработки:


$ npm install webpack-dev-server --save-dev 

Теперь добавим npm-скрипт в package.json:


{
  "name": "modern-javascript-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack --progress -p",
    "watch": "webpack --progress --watch",
    "server": "webpack-dev-server --open"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "moment": "^2.19.1"
  },
  "devDependencies": {
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.2",
    "babel-preset-env": "^1.6.1",
    "webpack": "^3.7.1"
  }
}

Можно запускать сервер разработки:


$ npm run server

Команда автоматически открывает index.html в браузере по адресу localhost:8080 (по умолчанию). При изменении JavaScript-кода в index.js webpack-dev-server будет пересобирать свой собранный в пакет JavaScript и автоматически обновлять браузер. Это действительно экономит время, потому что можно сосредоточиться на коде, а не постоянно переключать внимание с кода на браузер, чтобы просматривать изменения.


Есть много других опций для webpack и webpack-dev-server, мы лишь прошлись по самым верхушкам (подробнее тут). Также вы можете написать npm-скрипты для других задач вроде конвертирования Sass в CSS, сжатия изображений, запуска тестов — всего, что использует командную строку. Также много классных советов можно почерпнуть из выступления Кейт Хадсон:



Заключение


Мы вкратце рассмотрели современный JavaScript. Прошли от сочетания чистых HTML и JS до использования:


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

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


Но всё не так плохо, как может показаться. Ситуация устаканивается, node-экосистема всё больше воспринимается как жизнеспособный вариант работы с фронтендом. Удобство и согласованность в работе обеспечивается использованием npm в качестве диспетчера пакетов, node-выражений require или import для работы с модулями и npm-скриптов для запуска задач. И этот рабочий процесс гораздо проще, чем было год-два назад!


Фреймворки сегодня часто поставляются с инструментами, облегчающими начало веб-разработки. В Ember есть ember-cli, оказавший огромное влияние на angular-cli из Angular, create-react-app из React, vue-cli из Vue и т. д. Эти инструменты обеспечат ваш проект всем необходимым для того, чтобы начать писать код. Но они не волшебные палочки, они лишь правильно всё настраивают для комфортной работы. Нередко вам может понадобиться дополнительно настроить конфигурацию webpack, babel и т. д. И очень важно понимать, что делает каждый из инструментов.


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


Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (370):

  1. StarMarine
    /#10494026 / +2

    Следующий шаг — это полная поддержка импорт-синтаксиса es7 в node.js и webpack. Тогда всё будет окончательно изоморфно.

    • shelomanovd
      /#10494786

      Ну + бабель и в ноде ты можешь писать фул es6

      • Alendorff
        /#10497350 / -1

        Какое-то это тяжелое извращение транспайлить бабелем серверный код… :(

    • vitaliy2
      /#10497866

      В webpack итак поддерживается вроде даже без Babel (хотя это не так важно, т.?к. чаще всего Babel используется).

      В node.js поспевает.

      В браузерах уже.

      Поэтому и ждать уже особо и нечего :)

      • staticlab
        /#10497970

        В webpack итак поддерживается вроде даже без Babel (хотя это не так важно, т.?к. чаще всего Babel используется).

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

  2. misato
    /#10494052

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

    • T1MER
      /#10494064

      Полностью с Вами согласен. Большинство статей про старт во FrontEnd содержит в себе что-то вроде: «Скопируй этот текст в файл конфига вебпака и пока не обращай внимания, разберешься потом.» И как только появляется необходимость что-то подправить — проявляется ступор и синдром самозванца.

    • QtRoS
      /#10494850

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

  3. 4umak
    /#10494092

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

  4. Hateshinai
    /#10494118

    Статья как раз для меня. Очень вовремя. Только начал разбираться. Спасибо, стало понятнее.

  5. webdi
    /#10494126

    «Изначально npm создавался как диспетчер пакетов специально для node.js, среды исполнения JavaScript, предназначенной не для серверов, а фронтенда. Так что довольно странно применять его в качестве диспетчера пакетов для библиотек, запускаемых в браузерах.»

    Пардон, а нет ли тут опечаток и смысловых ошибок?

  6. ilyaplot
    /#10494152

    В одном из проектов наш фронтендер использовал gulp и stylus для css в 100 строк. Я посмотрел на размер папки node_modules и ужаснулся: вот, что занимает так много места на SSD.
    Понятно, что это только инструмент для разработки, но что же там такого «нужного» на 3 гигабайта? Хотелось бы иметь более изящное решение.

    • stardust_kid
      /#10494332 / -9

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

    • ivanovSP
      /#10494440 / +2

      А еще там не настроены игноры и все это уходит на GIT?
      не знаю что у вас там за пакеты, у меня любой крупный проект тянет за собой около 100мб node_modules модулей

    • balkhaev
      /#10494686

      3гб? Это очень много. У нас на крупных проектах с webpack, кучей loader'ов и т.д. он весит около 200мб.

    • dubr
      /#10494722 / +5

      но что же там такого «нужного» на 3 гигабайта?

      ну так package.json в студию, мы вам расскажем ))

    • Tarik02
      /#10494796 / +7

      • kekekeks
        /#10496592 / +1

        Это вы директорию с нугет-пакетами в дотнете не видели. Хорошо хоть сейчас всё в глобальное хранилище в домашней директории вынесли, а так 600-800 мегабайт на проект было нормой, а сейчас просто 10 гигабайт сразу на всех.

        • Tarik02
          /#10497248

          Зачем вы это мне написали?

    • Finesse
      /#10499858

      У нас в одном из проектов сборка CSS (stylus + autoprefixed) и JS (babel + rollup) через gulp. Папка node_modules весит 20,7МБ (40,1МБ на диске). Что может занимать 3ГБ, я даже не представляю.

  7. Zenitchik
    /#10494154

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

    ЩИТО? Переход на новую версию библиотеки — это отдельная процедура. Прежде чем переходить — нужно быть уверенным в совместимости старого кода с новой библиотекой.
    Автоматическое обновление всего, что поддаётся обновлению — весьма вероятно сломает проект.

    • RidgeA
      /#10494196

      Видимо речь идет о том, что для обновления библиотеки (по какой бы причине такая необходиомость не возникла) не нужно искать сайт библиотеки / репозиторий, а достаточно сделать, например,
      npm up lib@42

      • Zenitchik
        /#10494204

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

        • mayorovp
          /#10494366 / +3

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

        • nbelyh
          /#10494436 / -1

          Также для этого есть semantic versioning — минорные (ничего не ломающие) фиксы библиотек можно забирать автоматически.

          • vasfed
            /#10494772

            К сожалению, то, что минорные апдейты не должны ничего сломать — еще не означает, что они на деле ничего не сломают.

            • Aiditz
              /#10495288

              При подобных опасениях разработчик указывает в package.json точную версию библиотеки.

              • Igelko
                /#10495460

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

                • staticlab
                  /#10495476

                  теперь уже и package-lock.json есть

                  • Igelko
                    /#10495534

                    ну вот примерно об этом и речь.

    • mechanix13
      /#10494438

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

    • Aiditz
      /#10495290

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

      • musicriffstudio
        /#10495394

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

        • Aiditz
          /#10495688

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

          • musicriffstudio
            /#10496850

            представьте что вам не выплатили зарплату т.к. бухгалтерия положилась на совесть разработчиков 1С, а в последнем обновлении была ошибка. По ошибке чёто потерялось, что ж поделать. Может быть в следующем месяце исправят. Если получится то пересчитают зарплату за прошлый месяц, не получится — ну, значит пропала.

            Так понятней?

            • Aiditz
              /#10496896

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

              • musicriffstudio
                /#10496944

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

                Но если не надо обновлять то и никакой сборщик пакетов типа нпм не нужен.

                • Aiditz
                  /#10497498

                  Вы неправы, сборщик пакетов все равно нужен, для того, чтобы
                  1) не заливать все сторонние библиотеки в репозиторий проекта,
                  2) чтобы установить все и разом командой `npm i`, а не заходить на сайт каждой и искать где там кнопка скачать.

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

                  • andreymal
                    /#10497514

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

                    Прекрасный пример — питоновый PyPI, в котором лежат заранее собранные пакеты для всех архитектур для всех ОС (если об этом позаботились разработчики пакета, конечно); таким образом для установки каких-нибудь lxml или Pillow, написанных на чистой сишечке, ставить gcc не придётся. В итоге всё, что чаще всего делает pip install — качает whl-пакет и распаковывает куда надо. Каким бы сложным пакет ни был. Ничего никуда собирать не надо — всё сразу готово хоть для продакшена.

                    Не знаю, есть ли что-то аналогичное для жс (может и есть, однако на сайте npmjs.org я заранее собранных пакетов не нашёл), но то, что все ставят исходники пакетов через npm i и потом сами собирают всё бабелем вместо скачивания заранее собранного — явно ошибка эволюции жс :) (Но если я не прав и такое есть — просьба ткнуть меня носом, возможно я стану использовать такое в своих проектах)

                    • staticlab
                      /#10497554

                      А что вы подразумеваете под заранее собранными пакетами? Пакеты, готовые для исполнения на сервере через node.js, или пакеты для использования на клиенте? Если первое, то node.js сам по себе скушает ES6 и require. Если второе, то в абсолютном большинстве случаев node_modules и так исключается из препроцессинга бабелем.


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

                      • andreymal
                        /#10497624

                        Пакеты, готовые для исполнения на сервере через node.js, или пакеты для использования на клиенте?

                        И те, и другие. Если продолжать аналогию с питоном, то там все пакеты и так только для «сервера», и многие из них заранее собраны, чтобы не требовать установки местных аналогов бабелей (gcc, cython и прочий dev-хлам. При желании можно их поставить и собрать пакет самостоятельно через pip install --no-binary, но зачем, если всё уже собрано для нас?).


                        бабелем

                        А должно быть без бабеля! Я вот набрал, к примеру, «npm install jquery» и появился каталог node_modules, в котором несколько мегабайт нахрен не нужного хлама. Единственный нужный здесь файл — node_modules/jquery/dist/jquery.min.js 85КБ — вот только он и должен был скачаться (ну, может, плюс минимально необходимая мета-информация). В PyPI с pip дело обстоит именно так (с поправкой на питон). Я буду очень рад, если найдётся общепринятый аналог такого «минимализма» для жс (bower и yarn по умолчанию так же качают несколько мегабайт хлама, предположу что потому что сайт npmjs, в отличие от PyPI, собранные пакеты просто не хранит)

                        • staticlab
                          /#10497662

                          А должно быть без бабеля!

                          Вы читать умеете? Говорю же, что node_modules бабелем не обрабатывают — это долго и не нужно. И никто не мешает вообще не пользоваться бабелем и не подключать его в проект. Пишите свой код в ES5, и на выходе будут бандлы в ES5, потому что в пакетах по большей части и так есть собранные библиотеки.

                          • andreymal
                            /#10497670

                            node_modules бабелем не обрабатывают

                            И не надо обрабатывать node_modules бабелем! Надо скачивать заранее обработанное. В node_modules исходников библиотек вообще не должно быть ни в каком виде. А сейчас они есть. И это отвратительно.


                            (Вообще у меня есть сомнения в правдивости высказывания «node_modules бабелем не обрабатывают», но для проверить не хватает соответствующих знаний)


                            И никто не мешает вообще не пользоваться бабелем и не подключать его в проект.

                            Не мешает, я и не подключаю. Только вот получается две крайности: или подлючать несколько гигабайт nodejs-окружения со всеми исходниками всех зависимостей, или скачивать jquery.min.js вручную и класть его в репозиторий. Промежуточного варианта — скачивать только jquery.min.js автоматически с репозитория с плюшками типа автоматического обновления — нету, и это отвратительно.

                        • mayorovp
                          /#10497740

                          Я вот набрал, к примеру, «npm install jquery» и появился каталог node_modules, в котором несколько мегабайт нахрен не нужного хлама. Единственный нужный здесь файл — node_modules/jquery/dist/jquery.min.js 85КБ — вот только он и должен был скачаться (ну, может, плюс минимально необходимая мета-информация).

                          Это особенность jquery, где решили включить исходники в пакет тоже.

                          • andreymal
                            /#10497886

                            Такая особенность не у одного jquery (как минимум у bootstrap и у того несчастного topojson ещё), и это плохо. Нет единого стандарта (кто-то пихает сборку в dist, кто-то в build, кто-то вообще в что-то своё; кто-то с исходниками, кто-то без исходников, думаю есть те кто вообще пихает только исходники, но сходу таких не нашёл), заранее неизвестно что я получу при скачивании пакета, и это не даёт мне автоматизировать скачивание этих моих jquery.min.js. Ну и скачать сборку отдельно от исходников всё ещё нельзя.

                            • staticlab
                              /#10497992 / +1

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


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

                              • andreymal
                                /#10498054

                                пакеты npm никогда не были нацелены и оптимизированы под использование вне экосистемы commonjs

                                Ну и зря


                                cdnjs

                                О, круть) Но, я так так понимаю, общепринятых аналогов npm install и package.json с описанием зависимостей для cdnjs нету? Или плохо искал?

                                • justboris
                                  /#10498316

                                  Попробуйте unpkg. Этот сервис дает доступ к файлам из npm-модулей.


                                  https://unpkg.com/jquery выдаст вам искомый jquery.js файл.

                                  • andreymal
                                    /#10498322

                                    Только на jquery и выдаёт) Для react и bootstrap выдаются несколькострочники с require, которые для использования в браузере не годятся

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

        • Beyondtheclouds
          /#10496438

          достаточно только первого пункта, для остального есть mastercard package-lock

    • Finesse
      /#10499878

      Для решения этой проблемы есть стандарт semver. При подключении библиотек менеджеры пакетов ставят в файле-списке пакетов символ ^ перед версией пакета, что означает «подойдёт любая версия, совместимая с указанной». Так при обновлении библиотек через менеджер пакетов не произойдут обновления, ломающие обратную совместимость. Но всё это работает, если авторы библиотек достаточно ответственно следуют semver.

  8. Xandrmoro
    /#10494194 / -2

    Чувствую, что меня заминусуют, но зачем весь этот зоопарк, если старый добрый jQuery всё так же решает все возможные проблемы?

    (если вам вдруг нужен mvc на фронтэнде — вы что-то делаете не так)

    • andreymal
      /#10494234

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

      • aragaer
        /#10494434

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

        • bgBrother
          /#10495446

          В любой момент можете проверить что именно пишется на диск конкретным процессом.

          • aragaer
            /#10495636

            По ссылке что-то про какую-то конкретную операционную систему, которой у меня нет.

            А на диск пишет именно хром. И я уже выяснил, что ледо в web-версии телеграмма.

          • DummyBear
            /#10496078

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

            • bgBrother
              /#10496084

              Какой браузер? Если можно юзать Хром, то узнать сайт — не проблема (PID процесса-вкладки). Писать на диск можно или через LocalStorage и подобное (можно посмотреть инфу в DevTools), или через FileSystem API (нужны права). Возможно, я что-то упустил (не знаю?). Дебаггер советовать, наверное, нет смысла.

      • ivanovSP
        /#10494744

        Про какой web-мессенджер идет речь?


        • andreymal
          /#10494748 / +1

          Как минимум Slack. Вообще я немножко утрировал, но вот про полтора гига оперативы высказывались все кому не лень

          • Tallefer
            /#10495076

            Уже можно спокойно говорить «про любой». %) Ну или добавить Discord, если слака мало.

            • ivanovSP
              /#10495624

              discordapp.com — попробовал, у меня работает идеально, оперативки 100 МБ.
              Что не так конкретно?

              • Tallefer
                /#10495680

                попробовал
                «А включать-то пробовали?» :D
                Нет, ну ладно, примем, что для вебсофта 100 мб это «идеально»… Но в реальности это достижимо только при условии «не включать». %) То есть практически не пользоваться по назначению. Как в случае с браузерами — открывать две-три вкладки за сессию.

                • ivanovSP
                  /#10495840

                  Это нормальная цифра для такого сайта.
                  f6.s.qip.ru/etSMzb2V.png

                  Это тоже самое если я сейчас топовую игру запущу и буду жаловаться что она требует 8 ГБ оперативки.
                  У вас всегда есть выбор, взять десктопную версию приложения.

                  Если вы открываете 100 вкладок за сессию, то это ваша проблема, я же не открывать 100 фотошопов.

                  • Tallefer
                    /#10495854

                    А что такого в этом сайте? Вебчатики с прошлого тысячелетия существуют, а тогда 150 метров памяти это было бы больше физически доступной. %)
                    Я о «десктопе» и говорил, но, на самом деле-то нет никакой «десктоп версии», в этом и прикол! :D Это ровно тот же сайт, только крутится в электроне. Нет никакого выбора! %)
                    Не «если» открываю 100 вкладок, а «когда», потому что чатик — это не то же самое, что браузер (хотя и со страницами та же история, но это более общая тема), и у меня может быть сколько угодно контактов там, и их число не уменьшается. И проблема совсем не на моей стороне, я могу (и открываю) 100 вкладок в чем-то, отличном от электронных поделок и мне норм. :) А про 100 фотошопов — ооо, не надо так опрометчиво зарекаться-то, придет время и пооткрываете «фотошопы» во вкладках, уже вон в веб-версии переезжает все. ;)

                    • ivanovSP
                      /#10495862

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

                      Меня все устраивает, мне не западло потратить 150 Мб оперативки и 200 мб памяти на жестом диске.

                      Я вот недавно какой-то софт устанавливал ан комп, весил он 20 метров
                      . только вот он меня попросил скачать NET framework в 200 метров, по сути все тоже самое выходит, километровый софт ради простой задачи!

                      Мобильная разработка вас устаривает в 2017 году?
                      Я скачивал приложуху дял финансов весит она 200 метров.
                      Скачивал игрушку, весит 1 гб.

                      • Tallefer
                        /#10495884

                        Иметь загруженный ЭТОТ сайт не смогу, а построенный по старым канонам — да легко, и все остальное тоже. :)

                        Меня все устраивает
                        Вот в этом и проблема. :) Люди такие люди, к достатку привыкают быстро…
                        И опять же, 150 метров — меня бы тоже устроило (в десктопном софте на кутях это типа норма), но речь-то идет о гиг-полтора! :)

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

                        Меня — не устраивает, но я ее и не трогаю, мне нравится десятилетней выдержки. %)
                        Игрушку могу понять на гиг, там грофоний (2017 год опять же), а мобилы это как компы старые, когда как раз на гиг игры уже были. А приложуха, почти уверен, слабана на электроне или типа того, шоб сразу на все платформы деплоить.
                        Но что, Вас и это тоже устраивает?
                        — Самое интересное, что я не могу пока понять, откуда такое желание защищать текущее положение дел, особенно учитывая вот это коммент по которому видно, что автор полностью осознает причины происходящего. :)
                        Процитирую для удобства
                        javascript уже в мобильных приложениях и десктопе.
                        Экономия на сотрудниках.
                        Позволительно когда проекты не сложные и высокие знания особо не нужны.
                        Не знаю какой привести пример, но если вы делаете что-то типа: «Показать записи, сгруппировать, вывести комментарии, показать среднее число постов в сутки, отправить данных на клиента, добавить, отредактировать», то вам не нужен крутой бекендер, там особо много ума не нужно, подойдет и фронтендер со знаниями бека.
                        Если это что-то реально серьезное нужно сделать на беке, то такой разработчик уже будет плох.

                        • ivanovSP
                          /#10495906

                          Можно отключать как-то все современные фичи браузеров, но там заморочено, самый простой вариант это через плагин: The Great Suspender
                          chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg

                          Расход оперативки снизится на 90%.
                          Теперь вместо 40 вкладок у вас будет висеть только 1 вкалдка в оперативной памяти.
                          Это одна из альтернатив, уверен что существуют браузеры которые делают так по умолчанию.

                          Это на случай если вы не современный человек и у вас старое железо и 1ГБ оперативки.

                          Что касается электрона, я тоже хочу что бы все приложения в мире занимали по 5МБ памяти, вместо 300 мб.
                          Только вот софт такой стоить будет не 50 баксов, а 1000 баксов.
                          Потому что цена разработки повысится, а нафиг это нужно? я лучше уж оперативку куплю за 1000 рублей, чем буду вечно переплачивать гуру программистам.

                          но почему меня это не тревожит? А потому что оперативная память стоит очень дешево, я покупал 5 лет назад 2 планки по 4гб за 3500 рублей и мне это хватает по сей день, даже с избытком Вот если бы планки стоили по 30 000 рублей, тут бы я был зол. таких людей как я еще 95% на всей планете и всех всё устаревает.

                          • Tallefer
                            /#10495914

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

                            Цена на софт раньше почему-то не была выше, не надо вот. :3 Не цена разработки повысится, а скорость понизится, ну и снизится возможность использования веб-макак, само собой. Переплачивать приходится именно сейчас, тем, что покупать железо ТОЛЬКО ради ТЕХ ЖЕ задач, которые были решены уже пять-десять лет назад. %)

                            Именно так, 95% и всем норм. -_-

                            • ivanovSP
                              /#10495928

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

                              Я не хочу платить 10000 баксов гению низкоуровневого программирования фрилансеру, который будет пилить свой софт 2 года под все платформы.
                              Я лучше заплачу 100 баксов макаке (как вы выражаетесь) который быстро решит мою задачу и решит ее не хуже.

                              Мне проще докупить оперативную память за 1000 рублей, что я кстати сделал еще 6 лет назад и вам советую сделать тоже самое. :)

                              Можете рассказать какое у вас железо стоит?
                              Я покупал свой комп около 5-6 лет назад и он до сих пор тянет весь софт, сайты и прочую фигню,
                              Вот игры перестал тянуть, но там видюха слабая просто :)


                              • Tallefer
                                /#10495936

                                Тут явно путаница: работодатель платит за исполнение, не пользователь. А текущий тренд разработки пытается взвалить эту ношу на пользователя. С чем я в корне не согласен. %)

                                А вот я — хочу! Разумеется, 10 тыщ бачей не в одну каску, а вскладчину (и получается %кикстартер%), и опять же ошибка — платит разрабу не пользователь, а босс. Фрилансер тоже работает на босса — заказчика, кстати.

                                Так я не понял… ДЛЯ ЧЕГО память покупать? %) Если все и так тянет?
                                У меня примерно такая же жестянка, но сейчас я сижу на еще более старом ноуте.
                                Кстати да, тут уже давно должны были набежать с факелами и вилами владельцы модных ноутов, где память распаяна… %)

                                • ivanovSP
                                  /#10495950

                                  Я вас понял, я заказчик. сделаете мне за 50-100$ приложение которое будет запускаться на Android/IOS/WIN/UNIX/WEB?
                                  Срок — 1 сутки.
                                  Приложение простое, нужно разбивать загруженный текст на слова и делать по ним перевод через Yandex api + из полученных слов формировать цепочку карточек и показывать их в очереди.

                                  Около 50-100 строчек кода на JS не считая визуализацию блока.

                                  А вот хрен вы сделаете, вы запросите 500 баксов) потому что вам надо будет подключить к проекту еще 3 программиста и сроки увеличатся до недели.
                                  Вот о чем речь.

                                  • Tallefer
                                    /#10496014

                                    Ну так это мне решать, сколько я запрошу и какая у меня квалифкация. :) Допустим, что это можно сделать НЕ на жабоскриптев и в строк 20. Ну за срочность может и запрошу больше, или за еще какие-то хотелки, но какая разница? Я кстати не понимаю вообще смысла формулировки «не сделать, но запросить 500 бачей» и что из чего тут должно следовать и почему. %) Но у всех свой опыт, это да.

                                    • ivanovSP
                                      /#10496060

                                      Если сделаете мне этот продукт за 50$ на своем высокопроизводительном языке, что там у вас C++ или еще что, не разбираюсь в ваших технологиях, для меня важна скорость разработки и кросплотформеность ну и естественно что бы все работало и не лагало на современном железе.

                                      Цену устанавливаете вы, но и конкурентов у вас много на такую легкую задачу.

                                      • Tallefer
                                        /#10496076

                                        Ну если я такие пирожки выпекал бы по 10 в день, почему бы и не за 50 бачей? Я не вижу противоречия, опять. :)
                                        Конкурентов может быть и много, а заказчиков может быть еще больше…

                                • Beyondtheclouds
                                  /#10496442

                                  >Тут явно путаница: работодатель платит за исполнение, не пользователь.

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

                                  • Tallefer
                                    /#10496604

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

                          • sumanai
                            /#10496110

                            Только вот софт такой стоить будет не 50 баксов, а 1000 баксов.

                            Почему бы? Стоимость разработки это малая доля от стоимости конечной программы.
                            Иногда бывает лучше продать 1млн копий по 100 рублей, чем 100 по 10000.

                  • Massacre
                    /#10499412

                    В случае дискорда нет выбора, «десктопная» версия это тот же хромиум (и процессов по ~100мб будет уже от 2).

          • Igelko
            /#10495462

            Сейчас веб-версию слака сильно переписали в лучшую сторону. Десктопная версия пока что ужас-ужас. =(

        • bgBrother
          /#10495904

          Не мессенджер, но, интереса ради, можете сравнить pgAdmin 3 и pgAdmin 4 по скорости работы да хотя бы на i5-2520. Оба — десктопные приложения, второе — «web»-based. Я был шокирован.

    • Fractalzombie
      /#10494250

      После того, как я открыл для себя vue, я боюсь открывать jQuery код.

      • equand
        /#10494986

        Vue хорош всем, кроме того, что нужно дважды описывать модель во фронтенде и бекенде. Моя мечта написать backend defined frontend. Раз делал с jquery такое, но не до конца.

        • maxfox
          /#10495060

          Вы в этом желании не одиноки, но, судя по тому что никто пока не написал — это не так просто, как кажется.
          Наиболее очевидный путь — это ORM на JS, умеющая фронтенд. Но не все хотят JS на бэкенде…
          А еще есть PouchDB, которая синхронизируется непосредственно с CouchDB. Но вот CouchDB использовать не очень хочется, да и не всегда нужно тащить данные на клиент.

        • marshinov
          /#10495120

          Можете написать модель на беке и сделать генератор кода для vue на основе бек-модели. Работы на пару дней.

        • Infernion
          /#10497864

          Pony ORM вроде как предоставляет такую возможность, если я правильно понимаю требования docs.ponyorm.com/ponyjs.html

          • equand
            /#10498584

            К сожалению, не правильно поняли. Самое близкое это JamPy. Но оно больше всего подходит для работ с БД. Я говорю про следующую систему:


            У Вас есть готовый макро/микро-сервис. Вы просто направляете скрипт на описательный запрос и singleapp интерфейс генерерируется автоматически с socketio соединением и со всеми ограничениями и какими-то дефолтными настройками для этого. Все работает с серверной части для защиты endpointа ну и реалтаймовости интерфейса. Было бы круто сделать что-то вроде:


            route(endpoint_uri, endpoint_custom_name or domain_name, timeout, schema_uri or custom_schema)

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


            У меня еще этот говнокодец для mongoengine 0.8 ORM сохранился где-то. Конвертировало поля в list/dict и можно было работать и с референсами тоже. Только фронтенд я писал очень криво, шло определение по датаатрибутам, что делать и куда вставлять данные


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


            Допустим у нас апи клиентского раздела. Клиенту выдается сначала темплейт логин, после логина выдается темплейт интерфейса, если len(route) == 1 то сразу интерфейс апи, если len(route) > 1 то интерфейс каждого апи скрыт под submenu.


            Рут получает на входе credentials которые либо пересылаются в endpoint, либо обрабатываются декоратором и накладывают лимиты (апи фаерволл), согласно настройкам.


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


            @authorize(user)
            route('wss://mailserver', 'Mail', 10, 'wss://mailserver/api_help')
            @authorize(user,firewall_schema)
            route('https://rest.cpanel.lan/', 'Web', 10, 'https://rest.cpanel.org/schema')

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


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

    • Zenitchik
      /#10494260

      Ну, если Вы пишете сайты, то, вероятно такой подход годится. Я лично пишу не их, мне mvc на клиенте необходим.

    • potan
      /#10494390 / +2

      Зачем нужен jQuery, если есть ELM? ;-)

    • DieSlogan
      /#10494456 / +1

      Я еще помню, когда такие же вопросы звучали на тему jQuery: зачем нужен такой тяжелый фреймворк, если можно все написать на чистом JS?

      • vdasus
        /#10495454

        Просто попробуйте ru.vuejs.org/index.html. Я не фронтенд разработчик, пересмотрел кучу видеолекций по ангуларам, реакту и т.п. Тоже был в шоке от того как плохо живут фронтендеры и невозможно даже *просто выбрать* что-то из этих двух для начинающего работу с фронтендом. Одна статья хвалит, другая ругает… Определиться невозможно.

        И так пока не попался на глаза vue. Теперь взял и переписал простенький сайт с применением vue — скорость создания возросла раз в 10, количество ошибок меньше (заметно на глаз, даже без метрик). Писать — одно удовольствие. Не зря его хвалят, рекомендую. Буду использовать и в серьезных проектах, однозначно.

    • F0iL
      /#10494480

      Расскажите, пожалуйста, как ваш «старый добрый jQuery» может помочь с решением проблем использования возможностей ES6 в старых браузерах, с минификацией и с бандлингом? Заранее спасибо :)

      • stork_teadfort
        /#10494880 / +1

        Не подумайте, что я саркастирую, просто я из тех самых динозавров и мне действительно интересно — разве бандлы не зло? Раньше как было — ты добаляешь какой-нибудь jquery.js или bootstrap.js с CDN гугла, и со 146% вероятностью на клиенте он уже в кэше есть -> твой сайт грузится за пол-милисекунды -> profit!
        Т.е. удобство бандлинга действительно перекрывает тот факт, что клиенты в каждого приложения таскают одно и то же в составе различных многомегабайтных плюх?

        • mayorovp
          /#10494898

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


          Плюс любой CDN — это риски: он может перестать отдавать файл или начать тормозить и вы об этом никак не узнаете. Причем в последние годы на территории РФ эти риски многократно возросли.

          • FyvaOldj
            /#10495702

            Даже не "в РФ в последнее время" а в мире вообще.


            И не только по причине политических причин.


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


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


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


            Да, большие видео и много фото — есть смысл в CDN.


            Но для обсуждаемых здесь файлов JS — напротив — CDN это дополнительное слабое звено, согласен с вами

        • timeout2x
          /#10495036

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

          Каждый решает сам что ему важнее.

        • Tallefer
          /#10495086

          Как динозавр динозавру — ответ уже заключен в вопросе: ключевое слово — удобство. Разумеется, оно — для разраба, не для пользователя… %)
          А еще ломается вот такая офигенная (к сожалению, в прошлом) штука: https://addons.mozilla.org/ru/firefox/addon/decentraleyes/

          • Revertis
            /#10495526

            Почему в прошлом? Она и сейчас работает нормально. Даже на Nightly.

            • Tallefer
              /#10495546

              Ну вот из-за этой «компиляции», теперь CDN со статическими скриптами все реже используют, а аддон ничего не ловит в результате. Ну хоть память не жрет и то хлеб. :)

        • FyvaOldj
          /#10495666

          После того как я столкнулся с тем, что мой сайт, хостящийся у Google в GAE, не видим для Крыма. А после переезда на сервера в РФ — не видим как минимум в двух немелких городах (проблемы маршрутизации местных хостеров). После третьего переезда — не видим в других трех крупных городах....


          После чего я стараюсь минимизировать зависимость сайтов от внешних серверов.


          Свои ты хоть как то контролируешь и можешь вовремя заметить и принять меры

      • DrPass
        /#10495282

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

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

        • F0iL
          /#10495518

          ES6+ используют потому что это а) удобно б) помогает содержать код в чистоте и простоте.
          Зачем сознательно себя ограничивать в инструментах, если для их использования достаточно одной команды?
          А тот же TypeScript продуктивность разработки, к примеру, именно повышает, поскольку помогает отлавливать определенные ошибки еще на этапе сборки, а не в рантайме.

          На месте автора, я бы, кстати, ESLint еще упомянул, он тут тоже в тему.

    • Whuthering
      /#10494682 / +1

      Я бы сказал, «если вам НЕ нужен mvc на фронтенде — то или вы пишете helloworld/сайт-визитку, или вы что-то делаете не так».

    • SagePtr
      /#10494892

      Я первоначально думал также, но когда файл js начал занимать много экранов, то потихонечку задумался о том, что было бы неплохо разбить его на модули, а модули раскидать по файлам. Так и открыл для себя browserify, а потом и grunt, когда надоело руками каждый раз пересобирать файлы после каждого изменения. Ну а потом шли годы и появилось гораздо больше более удобных инструментов для сборки. Это не потому что так модно, просто реально намного удобнее, хоть и сходу трудно разобраться, что куда и как.

      • stychos
        /#10497652

        Я вот открыл requirejs и так и остался динозавром.

        • Zenitchik
          /#10498742

          Я попробовал его, и плевался от r.js. Никак не найду нормальный сборщик, чтобы define выпиливал и в костылях не нуждался...


          Я-то совсем динозавр, у меня stealJS с собственноручно написанным сборщиком. Давно хочу мигрировать на AMD, но вышеупомянутая проблема не даёт.

    • dubr
      /#10495302

      Я вам не скажу за весь MVC, но как минимум V на фронтенде нужен, если:
      1) пофиг на поисковики,
      2) а бэкендщики не хотят делать HTML, они хотят фыр-фыр-фыр хайлод, выбирать NoSQL, сетапить Docker и поднимать REST API.
      Старый добрый jQuery не очень умеет делать V из REST API.

    • vdasus
      /#10495456

      Просто попробуйте ru.vuejs.org/index.html. Я не фронтенд разработчик, пересмотрел кучу видеолекций по ангуларам, реакту и т.п. Тоже был в шоке от того как плохо живут фронтендеры и невозможно даже *просто выбрать* что-то из этих двух для начинающего работу с фронтендом. Одна статья хвалит, другая ругает… Определиться невозможно.

      И так пока не попался на глаза vue. Теперь взял и переписал простенький сайт с применением vue — скорость создания возросла раз в 10, количество ошибок меньше (заметно на глаз, даже без метрик). Писать — одно удовольствие. Не зря его хвалят, рекомендую. Буду использовать и в серьезных проектах, однозначно.

      Просто попробуйте, поймете что jquery и ванилла — это хорошо, но точно не везде и не всегда.

    • kraso4niy
      /#10497862

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

  9. rushe4ka
    /#10494226

    Спасибо, очень полезно

  10. noize
    /#10494228

    Славно, что я не фронтендщик. Верная смерть

    • ivanovSP
      /#10494466 / +1

      Все что тут описано учится за 1 неделю.

      • dom1n1k
        /#10494976 / -1

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

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

        • ivanovSP
          /#10495644

          Нужно уметь ориентировать в технологии и читать документацию.
          Не нужно зубрить весь синтаксис как в школе.
          Сколько вам потребовалось изучить GULP? годы? Перелопатили все пакеты?
          Мне ровно 30 минут, я понял общую концепцию посмотрел популярные библиотеки.
          И кстати я уже забыл как он работает, что бы освежить память мне нужно зайти на их сайт, прочитать около 10 строк текста.

          Webpack?
          Настроил 1 раз конфиг и забыл про него на пол года.
          Вышла новая фича — прочитал про нее — и перенастроил свой старый конфиг (используешь его под все проекты).

          Вышел новый Webpack _ прочитал нотацию о миграциях, переписал либо остался со старой версией

          • dom1n1k
            /#10495700

            Минут за 30 я уловил общую концепцию и получил иллюзию, что я что-то знаю. Набитые в дальнейшем куча шишек показали, что это была именно иллюзия.

            • ivanovSP
              /#10495760 / -1

              Если у вас что-то плохо идет в фронтенде, то проблема скорей всего вашем бекграунде.
              Это тоже самое что я полезу в ASP.NET без хороших знаний C# и буду жаловаться что там все криво и запутано, все не так как в других «серверных» языках.

      • altai2013
        /#10495286

        если бы это было правдой, зарплата фронтендеров была бы самой низкой в IT, а за каждую вакансию соискатели бились бы насмерть

        • Aiditz
          /#10495294

          В свое время, имея хорошие познания ванильного js и jQuery, потратил именно неделю на реализацию в своем проекте всего, что описано в статье. И это при том, что тогда не было такой статьи :)

          • vdasus
            /#10495464 / +1

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

            Знания нужны и если хотите делать как надо, а не чтобы работало — за неделю никак не осилить. Имхо, конечно

            • Aiditz
              /#10495690

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

              • vdasus
                /#10495716

                Так и статья и обсуждения, как мне кажется, не для матерых фронтендщиков, а для тех кто хочет или кому надо в это углубляться… Фронтендщики и так в этом живут.

              • ivanovSP
                /#10495774

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

        • maxfox
          /#10495404

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

      • PerlPower
        /#10495340

        Да, но устаревает все равно быстрее.

  11. serpentcross
    /#10494306

    Спасибо за статью!!! Очень досконально всё описано и легко читается! ))

  12. wsf
    /#10494312 / +2

    Хабр торт, для динозавров :)

  13. Zoolander
    /#10494324

    Спасибо. Если будут продолжения — буду ждать

  14. Zenitchik
    /#10494338

    Я динозавр и у меня остался вопрос: как отлаживать?
    Я так понял, что мне надо собирать проект каждый раз для запуска в браузере. А после сборки, а тем более — транспиляции, код будет не похож на то, что я писал, и ошибки, бросаемые браузером, мне нужно — как-то сопоставлять с исходниками.

    • faiwer
      /#10494396 / +1

      А тут либо выставлять sourceMap. Либо дебажить "как есть". К сожалению, sourceMap очень часто уступает второму подходу, хотя и визуально приятнее. В особенности когда вы привыкли во время дебага что-нибудь править на лету в консоли. К примеру вместо this.someVar на деле может быть _this.someVar. А вместо libraryFunction будет (0, _libraryFunction3.default). В общем тут на вкус и цвет. Страдать и дебажить огромные монолитные портянки babel-я, но видеть всё как есть и иметь больше возможностей, или же быть ближе к коду, но то и дело сталкиваться с какими-нибудь странностями.

      • andreymal
        /#10494402

        Кстати ещё насчёт дебага, меня учили старательно заворачивать всё в замыкания, чтобы в «global scope» ничего не торчало, что делает отладку через консоль невозможной в принципе, а также зачастую не даёт пофиксить какую-нибудь кривоту на чужом сайте через какой-нибудь юзерскрипт (и это одна из многочисленных причин, почему я осознанно остаюсь «динозавром»)

        • mayorovp
          /#10494414

          А какая связь между заворачиванием в замыкания и осознанным динозавром?

          • andreymal
            /#10494430

            У динозавров никто ничего обычно не заворачивает (в библиотеках типа jQuery такое бывает, а в коде самих сайтов я такое встречал очень редко), а у не-динозавров вебпак вроде бы всё сам заворачивает, если явно не пробросить что-нибудь в window. Исключения есть, но очень редки, отсюда и связь. Алсо, когда я пытался в вебпак-проекте вытащить пару модулей наружу в том числе для упрощения отладки, меня били по рукам)

            • mayorovp
              /#10494442 / +1

              Ну так почему вы осознанно остаетесь динозавром если вас учили заворачивать в замыкания-то?

        • faiwer
          /#10494426 / +1

          что делает отладку через консоль невозможной в принципе

          А зачем для отладки через консоль доступ к переменной из глобальной видимости? Ставите breakpoint или debugger, дожидаетесь срабатывания, открываете консоль и пишете в рамках видимости текущего стек-кадра. Очень сильно помогает в решении сложных debug-задач.


          А ещё частенько выручает на сторонних сайтах. Смотрите event-listener-ы нужных вам DOMelement-ов. Изучаете их callback-и ("развернув" код). Ставите в нужном из них точку останова. И вуаля. Есть доступ к чему угодно, можно делать что угодно. Манкипатчить функции, утащить значение какого-либо объекта, провести какие-нибудь эксперименты и пр… Ну в общем базовые debug-вещи.


          При использовании import-export системы модулей у вас все файлы по умолчанию обёрнуты в замыкание. Чтобы что-то навязать в глобальную область — это нужно сделать руками (window.blabla =, global.blabla =).


          В исходный код расширений тоже залезть проще пареной репы. Покопайтесь в web developer tools. Там столько всего вкусного есть… Времена когда инструментарий frontend разработчика был деревянным давно прошли.

          • andreymal
            /#10494450

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

            • faiwer
              /#10494460 / +1

              Мы, кажется, понимаем под словом debug с вами очень разные вещи. Если вам нужно публичное API — сделайте его. А если вам нужное публичное API для сторонних независящих от вас вещей — напишите им об этом в issue, или сделайте pull request, или просто свой fork, где будет всё по вашему. А для debug-а всё есть и область видимости слабая помеха.

              • andreymal
                /#10494696 / -1

                Если вам нужно публичное API — сделайте его.

                Я-то делаю, за меня волноваться не стоит.))


                А если вам нужное публичное API для сторонних независящих от вас вещей — напишите им об этом в issue, или сделайте pull request

                И все так сразу взяли, меня послушали и по-быстренькому запилили / приняли пулл-реквести, ага. Если бы всё так было в реальности, я бы тут не ныл про юзерскрипты. Один знакомый не-динозавр наоборот закрыл на своём сайте почти всё публичное API, несмотря на массовые протесты юзерскриптоделов, включая меня. При этом проблемы, которые ранее исправлялись юзерскриптами, исправлять, естественно, не стал.


                или просто свой fork

                Который будет никому не нужен. Огромное количество сайтов (включая вышеупомянутый) живёт в интернете только за счёт контента и аудитории, и если контент ещё можно кое-как скопировать (чем я старательно занимаюсь в свободное время, держа собственные копии некоторых сайтов), то аудитория будет переходить крайне неохотно, если вообще будет — пока технические проблемы не станут совсем уж невыносимыми. А будь форк сколь угодно крутым — какой в нём смысл, если народа не будет? Если разработчики отзывчивые, баги фиксятся, пулл-реквесты принимаются — проблема «замкнутого» API не столь остра, но ведь так бывает не всегда, и в моей практике «бывает» очень редко.


                А для debug-а всё есть и область видимости слабая помеха.

                Но помеха. Зачем эта помеха существует?


                Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?

                • faiwer
                  /#10494698

                  Но помеха. Зачем эта помеха существует?

                  Зачем существует область видимости? Масса причин. Загуглите. Кстати говоря, на подходе приватные поля классов (#someProperty). Так что помех будет ещё больше.


                  Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?

                  Проблемы индейцев шерифа… ;)

                  • andreymal
                    /#10494712

                    Зачем существует области видимости, я знаю, и активно их пользую. Вопрос в другом — зачем ограничивать доступ к области видимости? Python-way с эмуляцией приватных полей через подчёркивания я считаю хорошей идеей. Нарушать инкапсуляцию не позволят громко ругающиеся линтеры (я их юзаю как любой нормальный программист, естественно), а для отладки или костылей (когда без костылей совсем никак) — вот, пожалуйста, всё открыто, лезь куда хочешь.

        • mrsweet
          /#10496878

          Оборачивание снижает производительность. Для всего остального есть классы и babel

  15. stardust_kid
    /#10494340 / -6

    Статья хорошая. Только неблагодарная это работа объяснять невеждам. Если человек в 2017 году не понимает зачем нужен npm или webpack и при этом берется рассуждать о front end, то ему не нужны ваши объяснения, он просто хочет самоутвердиться.

  16. mayorovp
    /#10494346

    Вот объясните, зачем нужно указывать name, version, description, author, license и main если делается не общая библиотека, а веб-приложение или вовсе сайт? Кстати, вы еще repository забыли в список добавить. Не удивлюсь если эти поля в package.json самим своим существованием отпугивают динозавров...


    Для приложений достаточно { "private": true } и все. Или можно даже просто {} (пустой объект) в файле написать — npm будет кидать несколько варнингов, но работать.

  17. dz_here
    /#10494428 / +1

    Вроде бы статья добротная, но есть одно маленькое «но»: почти все перечисленные инструменты преподносятся как технологии обязательного использования в своих проектах, хотя это не совсем так. Gulp, Webpack, npm, yarn и другие представители «новомодного зоопарка» используються для облегчения разработки средних и крупных проектов. Нет смысла их использовать при малом количестве кода, тогда они будут просто мешаться.
    В 2017 ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript, даже нужно, если вы делаете простую верстку лендинга, а не полноценное веб-приложение.

    • sshikov
      /#10495010

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


      В 2017 ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript

      Не, тут вы не правы. Вы можете делать сто раз олдскульный сайт, но завтра к вам придет заказчик, и скажет, что хотел бы посмотреть сайт с iPad, например. Или из IE 11 (не говоря уже про более старые). И вам потребуется, чтобы ваш javascript вдруг сразу стал совместим с тем JS движком, который там работает. Вы все еще можете жить без npm, но вам уже нужен babel.


      Babel в принципе запускается например из JVM Nashorn, но вовсе не безпроблемно, в том числе потому, что сам в какой-то степени завязан на зависимости (пресеты и плагины).


      Вот это и мешает. Вы можете делать олдскульные сайты, но часть описанных тут инструментов все равно вам окажутся нужны. Менеджеры зависимостей, разного рода сборщики и пакеры — тут да, вариантов много (взять скажем gradle из того же мира Java). И их нужность конечно зависит от сложности, от наличия и числа зависимостей.


      Ведь по сути, весь npm, в той части, в которой он нужен простому приложению — это два-три тривиальных REST запроса к Node registry, один чтобы узнать список версий пакета, другой — чтобы достать tarball. Да, если там внутри окажутся скрипты для сборки — вы попали, но в простых случаях установка пакета npm куда-то на локальный диск — это строк 20 кода на чем угодно.

      • andreymal
        /#10495070

        вам уже нужен babel

        А чё, писать на чистом ES5 (опционально с полифиллами) уже запретили?)

        • Aiditz
          /#10495298

          Да и на ассемблере никто писать не запрещал. Но чем дальше в лес — тем менее становится актуальным чистый ES5. Проще потратить час/неделю (кому как) на освоение этой статьи, чем олдскульничать до старости. Ну то есть это уже становится по важности типа как знание гита.

          • andreymal
            /#10496062

            Ну, пока что лес не столь глубокий, лично я никаких проблем с ES5 не испытываю. Существенной разницы с ES6+ нет (без трёх с половиной синтаксических сахаров жить вполне можно, а для остального есть полифиллы), это вам не ассемблер. Да и у гита куча альтернатив есть, если что)

        • sshikov
          /#10495418

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


          Ну вот скажем, такой вполне реальный пример — есть Nashorn, который работает в JVM. Там кажется ES5.1, т.е. не самый последний. И я хочу там запустить что-то, что написано под ES6 (это не паковщик, и вообще это не инструмент, а вполне прикладная зависимость, какой-нибудь Topojson, скажем). Какая мне радость от того, что свой код у меня написан под ES5?

          • ameli_anna_kate
            /#10495580

            Многое еще зависит от сайта. Те же лендинги, с парой кнопок, формой и несколькими интересными эффектами можно доделать достаточно быстро, что бы работало красиво для мобилок, с помощью media queries. Почему нет? Если хочется только css, html, js.

          • andreymal
            /#10496070

            Разработчики Topojson заботливо прогнали всё через babel сами и залили минифицированную ES5-версию на гитхаб. И так с большинством библиотек, поэтому указанной вами проблемы не существует :)

            • sshikov
              /#10496470 / -1

              Агащазблин. На самом деле все еще хуже, чем я описывал. Во-первых, даже если прогнали и залили — вам придется лично копаться в скриптах, чтобы понять, это ES5, или какая-то другая версия. Потому что нигде в метаданных пакета npm это не пишется. И завтра в новой версии может оказаться другая, потому что никто вам ничего не обещал.


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


              P.S. Вот реальный код topojson:


              export {default as topology} from "./src/topology";


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

              • justboris
                /#10496746 / -1

                Вы точно разбирались в этом вопросе, или просто поныть решили?


                Вообще-то в package.json есть две секции


                • main — указывает на обычный CommonJS файл
                • module — указывает на код с import/export для тех окружений кто его поддерживают, например Node.js с флагом --experimental-modules.

                Для вашего особого случая, когда ваше окружение не знает ни require ни import авторы положили файл dist/topojson.js в котором модулей нет вообще.

                • sshikov
                  /#10496766

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


                  Окружение не просто не знает require и import, оно еще и не содержит npm (и node вообще). И речь как раз шла о том, что даже если вы пытаетесь писать в олдскульном стиле в любой среде, и на любой версии языка, то вам рано или поздно попадаются зависимости, которые хотелось бы использовать, которые просто требуют развертывания той экосистемы, которая описана в данном посте.


                  Ну т.е., беру я github, делаю себе clone — и на минуточку, там вообще нет папки dist, ага?

                  • justboris
                    /#10496776

                    Конечно в git папки dist нет, зачем коммитить сгенеренный код в VCS? Папка dist подготавливается в билде и публикуется в npm.


                    Если у вас нет возможности (или желания) ставить npm-cli, вы можете скачать файл руками: https://registry.npmjs.org/topojson/-/topojson-3.0.2.tgz, распаковать его, и получить заветные файлы из dist.

                    • sshikov
                      /#10496778

                      Я ровно об этом писал примерно 10 комментов назад. Читайте всю ветку, ваши комментарии спорят непонятно с чем.

              • andreymal
                /#10496820 / -2

                это ES5, или какая-то другая версия

                У любой нормальной либы указывается список поддерживаемых браузеров. Если такого нет или вместо него отписка типа «only for modern browsers», то это плохая либа, её использование — ваша ошибка, страдайте, чо уж :)


                вы можете захотеть внести в него исправления

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


                P.S. Вот реальный код topojson:

                Врать нехорошо

                • sshikov
                  /#10496888

                  Ни за что не поверю, что у вас это обыденность.
                  Хм. У меня в проекте пара сотен зависимостей. с десяток из них я лично дорабатывал. Доработка topojson, чтобы он работал в Nashorn, стоит в планах, потому что альтернатив ему найти не удалось,

                  P.S. Я вам показал реальный код, который лежит в github. А вы мне — вообще какую-то хрень непонятно откуда, из какого-то кеша. Для начала, попытайтесь понять, о чем я пишу, а потом уже наглейте до обвинений во вранье.

                  • andreymal
                    /#10496982 / -1

                    Доработка topojson, чтобы он работал в Nashorn

                    Значит официально Nashorn не поддерживается, значит на этом тему можно закрыть. Topojson фактически становится не сторонней зависимостью, а вашим кодом, а его пишите на чём хотите, хоть на ES3 — проблема зависимостей снова перестала существовать :)


                    А вы мне — вообще какую-то хрень непонятно откуда

                    Никакая не хрень, с гитхаба и скачано https://github.com/topojson/topojson/releases/download/v3.0.2/topojson.zip

                    • sshikov
                      /#10497098

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


                      То что в частном случае бывает иначе — я верю. Я даже могу поверить, что иначе бывает в 90% случаев. Это не меняет того факта, что вы полностью свободны в выборе инструмента только пока весь код сами пишете.

                      • andreymal
                        /#10497104

                        Если вам «повезло» попасть в эти проблемые 10%, мне вас жаль, но это не отменяет того факта, что необходимость иметь дело с тем набором инструментов, какой был у автора библиотеки — исключительная редкость. В поддерживаемых окружениях достаточно подключить вышеупомянутый topojson.min.js куда надо, и никаких бабелей ставить не надо.

                        • sshikov
                          /#10497116

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

                      • justboris
                        /#10497182

                        вам так или иначе нужно будет иметь дело с тем набором инструментов, какой был у их автора

                        под набором инструментов вы имеете в виду node.js/npm вообще, или конкретный инструмент сборки, которым собирается и тестируется topojson?

                      • Zenitchik
                        /#10497250

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

                        А когда Вы не весь код пишете сами — то весь разговор бессмыслен. О каком способе подключения зависимостей в коллективе ДОГОВОРИЛИСЬ — тот и надо использовать. И всего делов.

          • andreymal
            /#10496862 / +1

            Алсо, не расскажете, зачем вам Nashorn? Я про него нигде никогда не слышал, и не похоже, чтобы библиотеки тестировали и в нём тоже, а не только в браузерах и nodejs. А запускать библиотеки в заведомо неподдерживаемом окружении тоже немножко ССЗБ)

            • sshikov
              /#10496898

              Есть многое на свете, друг Горацио, что… Мало ли чего вы не видели и не слышали? У меня есть крупный Java проект, который работает с геометрией. Мне нужен конвертор geojson->topojson, который удалось найти ровно в одном экземпляре — у автора самого формата. У меня есть два простых варианта — либо его переписать (что возможно, но довольно геморройно, там много сложной математики), либо запустить как есть. А есть именно Nashorn, который декларирует ES5.1, и не умеет из коробки ни require, ни модулей.


              Тестировать? Ну так если что, протестируем. Это-то тут при чем? Даже если бы среда была поддерживаемая, все равно сторонним компонентам на 100% доверять нельзя.

              • andreymal
                /#10497000

                либо его переписать (что возможно, но довольно геморройно, там много сложной математики)

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


                Или у вас фиак-фигак и в продакшен и некогда кого-то куда-то портировать? Тогда все разговоры вообще не имеют смысла.


                Тестировать? Ну так если что, протестируем.

                Именно. Портируйте, тестируйте и на гитхаб ;)

                • sshikov
                  /#10497102

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

                  Вы не учитываете простой вещи — того что сегодня могут быть другие, более важные дела. Ну и потом, если я соберусь портировать скажем на Java, то а) скорее всего в основе будет либо JTS, либо geotools, и логика сильно может поменяться (надеюсь, в сторону упрощения), б) тесты можно будет выкинуть по большей части, тут они не помогут.


                  А геморрой с Nashorn — это совершено другого рода геморрой. По сути в основе него будет попытка перенести к себе окружение из Node. Скажем, npm подключить — это вообще не задача, я большую часть функций использовать не буду, а чтобы миррорить к себе выбранные пакеты из репозитория — это совсем простая задачка уровня "два-три REST запроса, выкачать tar.gz, распаковать". Я это уже почти сделал, там кода строк на 30 от силы.


                  require в каком-то виде есть, но надо состыковать с предыдущим пунктом.


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


                  Ну т.е. это — чисто техническая задача, по больше части рутина.

                  • staticlab
                    /#10497146

                    А пробовали для require использовать system.js?

                    • sshikov
                      /#10497372

                      Не, не пробовал. А оно разве поддерживает Nashorn? Я вроде видел баги у них в github, на предмет добавления, и они не закрыты, и там описаны проблемы, с которыми столкнулись в попытках это реализовать.


                      Вот, например: https://github.com/ModuleLoader/es-module-loader/issues/444


                      Вообще, в моем понимании тут ситуация пока такая, что нужна некоторая поддержка со стороны Оракла или OpenJDK. Иначе некоторые вещи сделать трудно.

                      • staticlab
                        /#10497380

                        Мдя, тяжко там у вас. Слушайте, а может быть будет проще поднять отдельный сервис на ноде, который будет конвертировать вам geojson в topojson? Кажется, это будет надёжнее, чем скрещивать бобика с паровозом.

                        • sshikov
                          /#10497388

                          По-моему у нас как раз все относительно хорошо :). Если я могу запустить Babel внутри JVM, и он работает — это совсем неплохо, и говорит о приличной совместимости JS движка.


                          Я не думаю, что в другой какой-то экосистеме (кроме самой ноды) получится сделать что-то похожее. Понятно что проблемы есть, но народ над Nashorn работает, его не забросили. Есть вот такая например штука, как jvm-npm, которая реализует requre (и которой я как раз пользуюсь). Если ей как следует объяснить, где у нас модули, и установить их заранее. И сделать сервис, который будет проксить node registry. Вполне реализуемая задача, на первый взгляд.

    • dubr
      /#10495044

      ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript

      Дело в пальцевой механике: если кодер пишет в основном на es6, он рано или поздно на автопилоте зафигачит в «олдскульный» JavaScript что-то типа let {foo, bar} = baz и даже не заметит (потому что сидит в последнем Хроме). В рантайме «новомодный зоопарк» жрать не просит, так зачем отказываться от привычного процесса?

  18. Hutaab
    /#10494432

    Очень полезно, только начал изучать js, многое встало на свои места, до этого команда npm install… походила на магическое заклинание. Спасибо.

  19. dubr
    /#10494758 / +1

    Обратите внимание на аргумент --save-dev?—?он сохраняет бандлер как зависимость среды разработки, так что она не понадобится на production-сервере.

    Это как? Если на проде нет сборки, то там и moment.js не понадобится. Если есть сборка, она без бандлера не заработает.
    На самом деле отличие в другом: если кто-то решит использовать ваш пакет как зависимость, ваши зависимости из devDependencies не будут подтягиваться в его node_modules.

    По сути, мы просим webpack найти все .js-файлы (за исключением лежащих в папке node_modules) и применить babel-транспилирование

    Мы не просим вебпак искать файлы. Мы ему объясняем что делать при импорте js-файла. В вашей формулировке получается что-то типа gulp.src('src/*.js'), но вебпак так не работает =)

    • mayorovp
      /#10494782

      Иногда нужно разделять модули на два типа не только при разработке библиотеки. Некоторые пакеты имеет смысл ставить не только там где идет билд — но и на сервере. В таком случае можно на сервере выполнить команду npm install --only=prod.


      В сценарии с webpack такая команда не нужна, а вот при использовании какого-нибудь require.js или systemjsразделение модулей на два типа пригодится.

      • dubr
        /#10494842

        Ну да, оно так и задумывалось, потому что и nodejs, и npm придуманы для работы в серверном окружении, и там эта конструкция вполне соответствует условному require/require-dev из композера. Но в случае, описанном в статье, все вполне однозначно: либо на сервер попадает готовый бандл, и там тогда тупо нет node_modules (то есть ни moment.js, ни вебпака). Либо оно там же и собирается, и тогда там будет и вебпак, и moment.js.

        Я не призываю все пихать в dependencies, порядок это вообще хорошо. Просто надо понимать, как оно работает, боюсь из статьи динозавр бы понял не совсем правильно +)

  20. tema_sun
    /#10494962

    Спасибо! Это, наверное, одна из самых полезных для меня статей за последний год на Хабре. Очень многое встало на свои места и теперь после уютного питоньего мира я могу смотреть на современный js без содрогания.

  21. Amomum
    /#10495012

    Статья действительно очень интересная, спасибо!

    И здесь появляется бандлер (bundler). Это инструмент для сборки модулей в единые пакеты, имеющий доступ к файловой системе. Получающиеся пакеты совместимы с браузером, которому не нужен доступ к файловой системе. В нашем случае бандлер нужен для поиска всех выражений require (имеющих ошибочный, с точки зрения браузера, JS-синтаксис) и замены на настоящее содержимое каждого требуемого файла. В финале мы получаем единый JS-файл без выражений require!

    Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?

    • staticlab
      /#10495030

      Я правильно понимаю, что в JS был, фактически, заново изобретен #include?

      include всё-таки более примитивное и низкоуровневое решение
      А как разрешаются кольцевые зависимости?

      В случае статических импортов будет ошибка сборки.

      • justboris
        /#10495250

        Не будет ошибки сборки. Проверил webpack 3.8.1, все собирается.

        • Aiditz
          /#10495300

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

    • mayorovp
      /#10495032

      Я правильно понимаю, что в JS был, фактически, заново изобретен #include?

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

      • Amomum
        /#10495184

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

        • staticlab
          /#10495208

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

    • Juma
      /#10495058

      Я правильно понимаю, что в JS был, фактически, заново изобретен #include? А как разрешаются кольцевые зависимости?
      Я вам больше скажу export/import уже даже поддерживается браузерами. Файлы со своими областями видимости и прочие плюсы.

    • justboris
      /#10495244

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


      А как разрешаются кольцевые зависимости?

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


      // a.js
      import b from "./b.js";
      
      // b.js
      import a from "./a.js";
      
      function logA() {
         console.log(a); // внутри функции можно
      }
      
      // а во время инициализации нельзя
      // console.log(a);

  22. TimsTims
    /#10495026

    Вот так мы создавали сайты с JS-библиотеками. Процедура была простой для понимания, но раздражала необходимость искать и скачивать новые версии библиотек при каждом их обновлении.
    Стоп-стоп-стоп… т.е. это и есть основная причина, по которой нужно городить такой зоопарк? Но ведь если раньше вам нужно было просто искать, скачивать и прописывать script src=, то теперь надо это делать в package.json, следить за зависимостями и множество других узких мест. Не могу сказать, что вы облегчили себе жизнь. Точнее «сначала усложнили», а потом автоматизировали.
    Но ведь и при обновлении новых версий библиотек нужно также быть очень аккуратным, ведь никогда не знаешь, поломает ли новая библиотека тебе сайт, или нет.

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

    В общем так и не стало особенно понятно, какую именно проблему решает такой метод, но зато расписано что и какой модуль делает, за это спасибо

    • mayorovp
      /#10495038

      Стоп-стоп-стоп… т.е. это и есть основная причина, по которой нужно городить такой зоопарк?

      https://habrahabr.ru/company/mailru/blog/340922/#comment_10494366


      Далее немного непонятно, зачем во фронте использовать библиотеки, предназначающиеся для полноценного серверного node?

      Незачем. Но в репозитории npm лежат еще и клиентские библиотеки. Собственно, npm выиграл (первую) войну пакетных менеджеров и сейчас практически все популярные открытые библиотеки можно найти в его репозитории.

    • staticlab
      /#10495046

      зачем во фронте использовать библиотеки, предназначающиеся для полноценного серверного node?

      ну так чисто серверные библиотеки на клиент никто и не тянет, зато есть много библиотек, которые способны работать и на сервере, и на клиенте, например, манипуляция с датами-временем, общие алгоритмы (обработка коллекций, строк), да и та же шаблонизация и view-компоненты


      сходу придумываю: sql-коннектор. или есть?

      WebSQL есть, поддерживают Chrome, Safari и т.п.


      А иначе выглядит как дикий костыль пихать в npm то, что не подходит для node, но подходит для фронта.

      npm — это общее хранилище пакетов для JS, поддерживающих соглашение CommonJS. Кажется, нет никакой причины делать для клиентских и серверных пакетов отдельные репозитории и утилиты, делающие одно и то же. Точно так же, как, например, в джавовском Maven или дотнетном Nuget лежат рядом библиотеки и для сервера, и для GUI, и никто по этому поводу не тревожится.

  23. Juma
    /#10495066

    Многое из описанного уже поддерживается в браузерах. Нет необходимости каждый раз после сохранения файла, пересобирать весь проект. Например, «import moment from 'moment';» в хроме уже работает. И практически весь остальной ES6. Но перед отгрузкой на боевой сервер кое, что из описанного понадобится: бандлер (webpack, rollup), транспилятор (babel), минификатор (uglify), еще можно и каким нибудь обфускатором прогнать. Настраивается один раз, и благополучно забывается до следующего проекта. Это если проект малый/средний.

  24. zenkz
    /#10495100

    Может я и динозавр, но ваша статья меня не убедила.
    Моё первое правило — минимум движений чтобы начать разработку. Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.
    В случае со всем этим зоопарком приложений — такое не сработает.
    Теперь пройду по порядку по каждому пункту:
    1. Использование диспетчера пакетов — диспетчер пакетов вещь хорошая, если она встроена в IDE (как NuGet в VS). Но как часто вы добавляете пакеты в проект? Я думаю это происходит в самом начале работы над проектом, плюс немного в ходе разработки. Раньше просто создавалась папка в проекте и туда помещались сторонние библиотеки (в отдельных папках), и всё это добро выкладывалось в систему контроля версий, поэтому для всех остальных разработчиков достаточно было просто забрать последние изменения. И это работает!

    Webpack — судя по описанию сценарий его использования — это создать себе проблему и героически его решать. Т.е. сначала мы пишем не-JS код, а потом его преобразуем. Почему бы сразу не писать JS-код. Не подключать библиотеки как раньше одной строкой с сылкой на файл?!

    Babel — примерно также как и Webpack. Я не понимаю зачем использовать синтаксис, неподдерживаемый браузерами. Если сейчас 90% браузеров поддерживают ES5, то пишите на ES5. Как только большинство браузеров стало поддерживать ES6 — переходите на ES6 и т.д. C HTML5 и CSS3 это отлично сработало, так почему для JS нужны костыли?

    TaskRunner — опять же полезная вещь, но только для минификации и оптимизации картинок, а не для «компиляции» JS — кода. В идеальном случае выполняется, как часть нового билда, а не как часть ежедневной работы программиста.

    Вообщем, как и положено динозавру, я буду продолжать писать JS-код, который не требует никаких преобразований и в браузере у клиента будет работать точно также как у меня на машине, а в случае крайней необходимости его и на проде можно подправить. Может быть года через 3-5, когда все браузеры будут поддерживать TypeScript или ES2016/2017 прямо из коробки, тогда уже буду использовать их. Но чтобы без «компиляции»…

    • mxms
      /#10495122

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

      • VolCh
        /#10495322

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

        • mxms
          /#10495406

          Ждал этого очевидного ответа. Но HTTP/2 решает эту проблему куда более эффективно. Особенно при использовании push.
          Кстати, о динозаврах, да? ;-)

          • staticlab
            /#10495480

            А вы уже используете HTTP/2?

            • mxms
              /#10495540

              Вовсю.

              • FyvaOldj
                /#10495738

                А браузеры ваших посетителей?

                • mxms
                  /#10495794

                  Все современные браузеры и довольно давно HTTP/2 поддерживают. Примерно сейчас 70% пользовательского трафика по нему идёт.
                  http://caniuse.com/#feat=http2

                  • FyvaOldj
                    /#10495880

                    Все современные и ныне используемые — это не одно и то же.


                    Скажем полно еще устройств с Android 4.2. Как раз в то время Андроид пошел в массы. И пользователи тех браузеров зачастую пользуются именно дефолтным системным.


                    А если бы проблема была только в степени реализованности фич в современных браузерах, то мы бы даже не использовали babel

                    • mxms
                      /#10495908

                      ~70% обращений клиентов (без роботов) по HTTP/2 это реальная статистика у меня в этом месяце.

                      • FyvaOldj
                        /#10497224

                        Я вас правильно понял: вы забили на 30% ваших пользователей?

                        • andreymal
                          /#10497236

                          Почему забили? Неужели то, что у 30% пользователей скрипты загрузятся на полсекунды дольше, это такая трагедия?)

                          • mxms
                            /#10497466

                            В два-три раза (от сайта) где-то реальное ускорение по HTTP/2.

                        • mxms
                          /#10497458

                          Я хочу сказать, что для конечного пользователя HTTP/2 это хорошо и нужно, а целесообразность пакетирования Javascript-ресурсов весьма сомнительна.

          • mayorovp
            /#10495570

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

            • mxms
              /#10495798

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

              • mayorovp
                /#10495828

                При сборке пакета webpack модули находит там же куда их положил npm. А вот клиентским скриптам такой механизм недоступен

        • mxms
          /#10495548

          Кстати, ещё момент. Описанный процесс упаковки вряд ли стоит сравнивать с компиляцией, поскольку никакого преобразования кода при этом не происходит. Вот кабы при этом была, хотя бы, некоторая (автоматическая) оптимизация за счёт, к примеру, удаления неиспользуемых функций и т.п., тогда я бы понял смысл.

          • staticlab
            /#10495562

            Tree shaking сейчас в вебпаке есть.

          • faiwer
            /#10495630

            удаления неиспользуемых функций

            В какой-то мере присутствует. Плюс может всякие статические выражения рассчитать. Может внедрять свои переменные в код и срезать неиспользуемые куски кода. Скажем было:


            if(process.env === 'DEBUG')
            {
               // a lot of code
            }

            стало… нифига не стало, всё срезало, ибо process.env === 'PRODUCTION'. Таким макаром срезается для prod-режима гора кода, предоставляющая удобства для дебага. Плюс минификация в prod-режиме.


            Ещё ряд плагинов именно преобразуют код. Скажем JSX плагин только этим и занимается по сути. А есть плагины к нему, которые превращают <If condition={}/> в тернарные операторы а <For .../> в .map-конструкции.


            Чего там только не, если честно.

            • mxms
              /#10495802

              Интересно, спасибо. Странно, что такой мотивировки пакетирования нет в статье.

        • sumanai
          /#10495640

          Как минимум, для загрузки всего js у вас будет лишь один http-запрос.

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

          • staticlab
            /#10495668

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

            • sumanai
              /#10495824

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

              • staticlab
                /#10495832

                Я не об этом говорю, а о проблеме дробления фронтенда на отдельные модули так, чтобы они соответствовали разным ролям, но при этом решали бы функции (в смысле UX) из одного контекста.


                Например, пусть у нас есть комментарии на странице. Каждый пользователь может удалить или отредактировать свой пост, если на него никто не ответил, а также любой пост может удалить, скрыть или отредактировать модератор в любое время. В "однофайловом" фронтенде решается тривиально проверкой прав и условий для каждой из функций, но если в приложение грузятся отдельные модули core, user, admin, которые могут добавлять функции в один и тот же контекст, то для этого нужно специально проектировать архитектуру, которая внесёт побочную нагрузку. Разумеется, если в большом сложном SPA можно вычленить вполне независимые большие модули, то всё это вполне можно и нужно разделить по отдельным бандлам.

    • staticlab
      /#10495130

      Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.
      В случае со всем этим зоопарком приложений — такое не сработает.

      Так никто не мешает создать пустое веб-приложение из шаблона.


      Раньше просто создавалась папка в проекте и туда помещались сторонние библиотеки (в отдельных папках), и всё это добро выкладывалось в систему контроля версий, поэтому для всех остальных разработчиков достаточно было просто забрать последние изменения. И это работает!

      Вы кладёте бинарные зависимости в контроль версий?


      Webpack — судя по описанию сценарий его использования — это создать себе проблему и героически его решать. Т.е. сначала мы пишем не-JS код, а потом его преобразуем. Почему бы сразу не писать JS-код. Не подключать библиотеки как раньше одной строкой с сылкой на файл?!

      Предлагаете браузеру выкачивать 100500 файлов библиотек и исходных кодов приложения? Даже в ASP.NET есть встроенный бандлер.


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


      Babel — примерно также как и Webpack. Я не понимаю зачем использовать синтаксис, неподдерживаемый браузерами. Если сейчас 90% браузеров поддерживают ES5, то пишите на ES5. Как только большинство браузеров стало поддерживать ES6 — переходите на ES6 и т.д. C HTML5 и CSS3 это отлично сработало, так почему для JS нужны костыли?

      На ES6+ пишут, главным образом, по одной простой причине: это удобнее и исходники получаются компактнее. Что в этом плохого? Кстати, для CSS3 вы префиксы вручную расставляете?


      TaskRunner — опять же полезная вещь, но только для минификации и оптимизации картинок, а не для «компиляции» JS — кода. В идеальном случае выполняется, как часть нового билда, а не как часть ежедневной работы программиста.

      А как запускать, например, тесты? Нужно ли делать это ежедневно программисту? А ещё каждый день запускают dev-сервер вебпака, чтобы разрабатывать.


      К слову, в серьёзных больших проектах "компиляция" делается на CI-сервере.


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

      Потом благополучно забыть внести в source control и огрести регрессий в следующий деплой.

      • serf
        /#10495146

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

        А еще на TypeScript пишут например, и там уже дело не только в красоте (синтаксическом сахаре).

      • zenkz
        /#10495164 / -1

        Так никто не мешает создать пустое веб-приложение из шаблона.

        Так помимо шаблона ещё требуется установка зоопарка приложений и их конфигурация.

        Вы кладёте бинарные зависимости в контроль версий?

        Вы не поверите, но да. Для сторонних библиотек считаю это допустимым.

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

        Если в вашем приложении 100500 файлов библиотек, то я бы задумался о том, всё ли вы делаете правильно… А бандлер в ASP.Net используется для минификации и для того, чтобы написать одну строчку кода вместо 10 для подключения зависимостей.

        На ES6+ пишут, главным образом, по одной простой причине: это удобнее и исходники получаются компактнее. Что в этом плохого? Кстати, для CSS3 вы префиксы вручную расставляете?

        80% того что есть в ES6+ — синтаксический сахар. Решается написанием своего метода, с последующей заменой кишков на ES6 комманду в случае миграции.
        Я и на старом-добром JS не жалуюсь на длину кода… Про префиксы к CSS3 — может у меня нет изысков в дизайне, но префиксы чаще всего не нужны и современные браузеры знают команды без префиксов.

        А как запускать, например, тесты?… серьёзных больших проектах «компиляция» делается на CI-сервере.
        И тесты запускаются там-же. Либо вручную перед коммитом.

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

        • staticlab
          /#10495180

          Так помимо шаблона ещё требуется установка зоопарка приложений и их конфигурация.

          Шаблон на то и шаблон, что там это всё уже вместе сконфирурировано и создан скелет приложения. Установить же "зоопарк приложений" — дело техники. Для этого npm и нужен. MSBuild/Nuget или Gradle/Maven то же самое при первом запуске сборки делают.


          Если в вашем приложении 100500 файлов библиотек, то я бы задумался о том, всё ли вы делаете правильно…

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


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

          Вот вебпак как раз этим и занимается. И вы не поверите, но на ASP.NET весь бэкенд не заканчивается, а фронтенд там тоже писать надо.


          80% того что есть в ES6+ — синтаксический сахар. Решается написанием своего метода, с последующей заменой кишков на ES6 комманду в случае миграции.

          То есть использовать готовый babel для этого нельзя, нужно писать свой велосипед?


          префиксы чаще всего не нужны и современные браузеры знают команды без префиксов.

          Современные браузеры-то знают, но требования к целевым браузером ими, к сожалению, не ограничиваются.


          И тесты запускаются там-же. Либо вручную перед коммитом.

          А как их запускать, если вы task runner запретили?


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

          Уж лучше совсем не иметь такую возможность. Код фронтенда ничем не лучше и не хуже кода бэкенда. Всё должно идти в нормальном пайплайне, пусть даже и по веткам hotfix в случае форс-мажоров.

          • zenkz
            /#10495190

            Не буду дальше спорить. Я же не отказываюсь от всех этих вещей вроде TaskRunner-а и прочих babel-ей. Просто им место в процессе билда новой версии системы, а не на машинах программистов. Мне как программисту хочется видеть следующее:
            — Запустил IDE
            — Создал новый проект
            — Написал код
            — Нажал выполнить
            — Открылся браузер и в нём всё работает
            — Если вижу ошибку, то иду в средства отладки браузера и сразу нахожу место поломки
            — Возвращаюсь в IDE на эту строчку кода и исправляю

            • staticlab
              /#10495214

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


              Да, вот так весь этот зоопарк сейчас и работает.

            • VolCh
              /#10495326

              Чтобы всё это работало на машине разработчика должны быть установлены билд-инструменты. при установке той же VS для C# устанавливается компилятор C# и никого это не смущает.

        • FyvaOldj
          /#10495746

          Если в вашем приложении 100500 файлов библиотек, то я бы задумался о том, всё ли вы делаете правильно…

          У вашего оппонента была всего лишь гипербола.


          Эффект заметен уже на паре десятков файлов

        • FyvaOldj
          /#10495754

          Так помимо шаблона ещё требуется установка зоопарка приложений и их конфигурация.

          Это ваша работа. И всего лишь ваши рядовые профессиональные инструменты.
          Не ничего страшного. Если это ваша постоянная работа.


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

    • mayorovp
      /#10495162

      Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.

      Visual Studio давно уже поддерживает TypeScript именно в таком режиме. И да, вместе со студией ставится нода довольно старой версии исключительно для запуска tsc или каких-нибудь grunt.


      А в ASP.NET Core, к слову, из коробки поддерживается использование внедренной ноды для изоморфного рендеринга.

    • dreka5
      /#10495314

      как динозавр динозавру отвечу.
      nmp это хорошая тема. поначалу бесила, потом норм (см ниже). Nuget уже торт.
      студия 2017 тяжела и не поворотлива. перешел на VS Code
      Конечно этот зоопарк реально бесит, но потом как то привыкаешь.
      переходим на Kestrel net Core. не надо никаких большее IIS'ов.
      и как вишенка на торте — плавный переход на Centos. И вот там все выше перечисленные шаги работают.
      прелесть Kestrel — это линух/виндос, легковестность, И привычная, удобная отладка кода. в отличии от Ноды и ГО. так что как динозавр динозавру рекомендую. b vim уже не кажется чем то диким.
      вобще связка Vue+Core(+Go)+Linux это то, куда стоит смотреть. Go пока нужен. Нода наврятли.
      и да, Kestrel, в отличии от GO,Node позволяет правку в рантайме на брекпоите. что в студии, что в vc code.

      • mayorovp
        /#10495576

        То есть изоморфный рендеринг вам не нужен совершенно, даже в перспективе?

    • VolCh
      /#10495338

      У пакетов два преимущества: простая и унифицированная проверка и установка обновлений, а также отсутствие необходимости (но не возможности) хранить пакеты локально, скачивая их при разворачивания.

      ВебПак не компилятор, а линковщик.

      Пишем код на ES5 для 90% браузеров и тут заказчик/начальник говорит «на ие9 5% сидит ещё, давай-ка и его поддерживать». В случае наличия транслятора только таргет изменим/добавим…

    • ivanovSP
      /#10495750

      Может я и динозавр, но ваша статья меня не убедила.
      Моё первое правило — минимум движений чтобы начать разработку. Т.е. когда я открываю Visual Studio и создаю ASP.Net проект, то могу нажать Run и он сразу заработает.



      Но а если это сделаю я, то у меня ничего не получится, потому что я не знаю какие пакеты устанавливать в вашем Nuget, я не знаю как устанавливать и конфигурировать всякие entity и прочее добро.
      Почему я не знаю этого и мне сложно понять как это работает? Я считаю что нужно очень много телодвижений что бы развернуть свою сайт визитку на ASP.NET под Windows.

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

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

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

      А почему вас беспокоит как работает WebPack? Это его проблема, вам нужно просто нажимать CTRL+S и ваш проект автоматические погонится через WEbpack, у меня это занимает около 1 секунды на старом железе.

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

      Зависит от проекта, где-то реально лучше использовать Jquery.
      Люди которые несут Angular в сайт визитку — идиоты.

    • vitaliy2
      /#10498498

      В статье плохо объяснено, зачем нужен WebPack. А нужен он:

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

      2. Для возможности модульной разработки. Вы не представляете, как это нужно. Без неё разработка сильно затруднена из-за большого количества причин. Сейчас модули стали поддерживаться нативно в браузерах, но WebPack нужен всё-равно, т.?к.:
      1) Поддержка введена очень недавно, а в некоторых браузерах ещё работает только с флагами.
      2) При уровне зависимостей больше 1 не требуется прописывать все подзависимости вручную, чтобы не замедлить загрузку (иначе браузеру придётся вначале грузить первый уровень, потом второй и т.?д.).
      3) Не нужно указывать все модули в index.htm, чтобы не замедлить загрузку.
      4) Удобная работа с node_modules и сторонними модулями.
      5) Более быстрая загрузка бандла (спорный момент из-за HTTP2). Не нужно переживать, что когда-нибудь модулей станет слишком много.

      3. Для объединения с минификатором. Конечно минифицировать можно и без Babel, но у вас на это уйдёт не меньше времени, чем на изучение Babel и использование уже готового решения.

      4. В webpack много функций — захотели препроцессор для CSS — не проблема. Захотели что-то ещё — не проблема. Конечно же, можно писать свои модули для webpack. Если вам что-то вдруг понадобилось, вы больше не скованы необходимостью изучать вебпак.

      4.1. Ну, кроме препроцессоров для CSS возьмём, к примеру, модуль «define». Для тестирования у вас может быть дополнительный код в проекте, а при сборке дефайны заменятся на сами значения, после чего неиспользуемый код полностью вырежется минификатором. Удобно и очень логично.

      В общем, как видно, всё это можно сделать и без вебпака, но это будет сложнее, чем изучить вебпак.

      Конечно же, начать проект можно и без вебпака — при этом 1) он будет работать только в определённых браузерах, 2) может понадобится настройка браузера, 3) он будет работать медленнее, но в итоге всё-таки будет работать, т.?е. добавить вебпак можно не сразу, а немного позже, тем самым упростив себе жизнь и сильно расширив список возможностей, которые можно использовать в проекте.

      Лично у себя я делаю, чтобы js-код мог работать и без вебпака (например, при тестировании), но клиентам отдаётся бандл, собранный вебпаком.

  25. serf
    /#10495138

    Ладно обычные JS npm пакеты, но это вы еще про WebAssembly забыли, и биндинги к нативному коду, а еще Electron приложения, и все это тоже JavaScript.

  26. mSnus
    /#10495324

    Я, как динозавр, привык, что если я делаю сайт — он прослужит лет 5, и если что — его можно будет через 5 лет спокойно подправить, а не переписывать с нуля. А этот «стек технологий» через 3-5 лет окажется ворохом непонятно работающих, неподдерживаемых и сбоящих механизмов. Потому что сами инструменты устаревают, форкаются, модифицируются с дикой скоростью — мы еще не поняли, нужен ли нам Grunt, а он уже устарел, вместо него Gulp, и так далее.

    И чтобы все это работало, придется искать Babel «той самой версии 2017 года, когда ES9 еще не было», от npm отказаться, потому что половина библиотек переедет на другие сервера, а webpack окажется давно заброшен, «так как в стандарте еще в 2019-м появились нормальные инклюды».

    И вместо того, чтобы легко найти и поправить строчку в нужном файлике, придется искать детранспилятор Unbabel, распаковщик webunpack, и по крупинкам вычищать синтаксический сахар «еще того года».

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

    Одним словом, эти технологии через еще 5 лет поменяются до неузнаваемости, окажутся уязвимы или просто отпадут. Будет, уверен, нормальный менеджер пакетов с графическим интерфейсом, отвалится Babel и Webpack за ненадобностью. Это мода, гонка за новыми технологиями, причем до того, как они будут достаточно отлажены.

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

    P.S. Мне тут один старый заказчик недавно позвонил — «помнишь, ты нам в 2000 году сайт делал? Вот он что-то перестал русские буквы показывать нормально...» Нехилый аптайм в 17 лет… и все вылечилось правкой collation ;-) я даже не помню, какой версии PHP тогда был… и работает зараза!

    • dreka5
      /#10495330

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

    • VolCh
      /#10495336

      Вы, как, с DOS уже перешли? :) Или CP/M?

      А если серьёзно, то всё что вам нужно будет лет через 5 — развернуть виртуалку с нужной версией node.js. Собственно, можно начинать работу над проектом с создания виртуалки с выбранным дев-окружением и работать в ней. Другой вариант — разворачивать его прямо на сервере заказчика, хотя бы перед сдачей.

    • AlexanderY
      /#10495428

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

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

    • mayorovp
      /#10495592 / -1

      И в чем же проблема использования устаревших инструментов? У вас что, кто-то их отбирает? Не вижу ничего неправильного в том, что проект начинается с использованием самых свежих инструментов, а потом 10 лет развивается без переписывания на новый стек технологий.


      Искать babel "той самой версии" не придется потому что, во-первых, новый стандарт должен быть совместимым со старым, а потому ваш код без проблем скомпилируется новым babel. А во-вторых, все версии babel от начала времен с самой первой лежат в репозитории npm, и никто не запрещает использовать любую, даже если разработка babel прекратится. В-третьих же, эта самая версия "того самого babel" при условии непрерывности работы над проектом должна лежать у вас в node-modules.

      • mSnus
        /#10495990

        Ну вот, навскидку — https://m.habrahabr.ru/post/310302/


        Годовой давности пост. Сейчас как этот подход, ничего не устарело, не поменялось? Redux, Koa (новый фреймворк нового поколения!), Helmet — это все по-прежнему?

        • mayorovp
          /#10495992

          Так что, тот проект перестал работать с выходом какого-нибудь Vue — или как?

        • staticlab
          /#10496002 / +1

          Это ещё вполне годный стек.

        • ivanovSP
          /#10496022

          Что бы знать Node.js нужно знать ES5 ES6 ES7
          Что бы знать Express Нужно знать HTTP
          Я не знаю KOA, но я уверен что он такой же как Express и он также наследуется от HTTP
          Обучится я смогу за пару вечеров.

          Я не знаю VUE.JS, но уверен что мне потребуется ровно неделя, для того что бы пересесть с REACT.
          И так далее.
          Мне — легко.
          тяжело тем кто не является веб разработчиком и пытается что-то сотворить, что бы не тратить деньги на найм веб разработчика.

          • mSnus
            /#10496220

            Дело в том, что даже вам потребуется неделя, чтобы пересесть на проект, который год назад был прям таки bleeding edge. А ещё через год-два вам уже потребуется не неделя, потому что вы будете работать на REACT++##.

            А ещё окажется, что не зря вы сидите на REACT, а не на VUE, потому что VUE был с какими-то косяками и его забросили, фиксы три года уже не выпускаются.

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

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

            • mayorovp
              /#10496444

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

              Не путайте "мешают" и "не так сильно ускоряют как современные".

            • ivanovSP
              /#10496750

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

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

              Но почему я это не делаю? А потому что у нас руководство хорошее, оно выбрало только 1 технологию, если вдруг мне покажется что REACT говно, то я уволюсь с работы и через месяц буду искать работу на Vue.

              Сейчас сотни фреймворков, но это лишь цифра, на деле только 2-3 актуальны, остальные никому не нужны, так же и с CMS, актуальны только 3-4.


              А ещё окажется, что не зря вы сидите на REACT


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

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


              По этому нужно оставлять в системе DOS, сервера крутить на windows sever 2003, а программистов искать под DELPHI 7?


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


              Если пройдет 5 лет и REACT умрет, а через 10 лет руководитель скажет: «ну вот, не найти теперь спеца, зря мы тогда выбрали react»
              То тут вина руководителя, он идиот и ему вообще не следует быть руководителем.

              Вот это ад:
              hh.ru/vacancy/22869652?query=delphi%207

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

    • FyvaOldj
      /#10495870

      5 лет работает и еще 5 лет обновлять?
      Да за это время целые эпохи в Вебе прошли.
      Делаю сайт 11 лет. Переписывался с нуля уже 5 раз.
      Уж очень его владелец хочет чтобы сайт ему бабло приносил. Посему — вкладывается

    • ivanovSP
      /#10495934

      Я, как динозавр, привык, что если я делаю сайт — он прослужит лет 5

      Но только вот через 3 года вы уже не сможете поддерживать свой продукт другим человеком.
      Попробуйте сейчас найдите специалиста на DElphi 7, никто не пойдет работать на Legacy за обычную зарплату, потому что Legacy это карьерная смерть.

      От таких работодателей нужно бежать как от огня.
      У таких работодателей как правило в компании даже JIRA нет и все вопросы решаются по телефону или почте mail.ru

      • FyvaOldj
        /#10497228

        Тем кто работали в эпоху широкой распространенности Дельфи 7 — сейчас около 40 лет, а это расцвет профессионального уровня. Эти люди еще работают и полны сил.

        Вы наверное имели ввиду не «не найдешь», а «не найдешь дешевых студентов» на Дельфи 7

  27. beduin01
    /#10495386

    Я просто оставлю тут ссылку github.com/arcanosam/imgui_wasm_demo
    Так что скоро на JS наконец то можно будет забить.

    • Opaspap
      /#10495412

      я как-то пробовал прозрачный (дырка) канвас положить поверх видео, ну чтобы UI из канваса можно было на видео накладывать, рамочки там, знаете всякие (рекламная область)… в общем печальный стопмошен получился.

  28. beduin01
    /#10495410

    Современный Веб разжирел до невозможности. У меня куча сайтов просто жесточайше тормозит просто потому что их пишут с использованием «модных» технологий.
    JS эволюционирует с бешеной скоростью и в этих стандартах уже черт ногу сломит. Ситуацию усугубляет набор постоянно устаревающих инструментов, которые тоже взаимонезаменяемы. Их нужно практически с нуля осваивать.

    По факту эта эволюция не может идти бесконечно. Старое legacy нужно выбрасывать. Очевидно, что это позволит сделать тот же WASM, который сам по себе разумеется не убьет JavaScript, но зато позволит появиться\выйти на рынок языкам, которые позволят писать сайты без всего этого геморроя.

    • ivanovSP
      /#10495678

      Покажете пример такого сайта?
      не прошу 100, не прошу 1000.
      Хотя бы 1 или 2 сайта.
      Именно сайты, т.е. через которые заходим по http://

      • ooprizrakoo
        /#10495940

        Не знаю, насколько сгодится пример: www.linkedin.com (залогиньтесь только)
        Я его использую по работе, и субъективно — это сплошной тормоз.

        • staticlab
          /#10495964

          LinkedIn — это какой-то лютый говнокод. Кстати, использует Ember.

        • ivanovSP
          /#10495976

          Залогинился у меня 13 000 контактов там.
          Сижу через прокси, потому что сайт заблокирован в РФ.
          Могу заснять видео, что у меня все быстро работает, ничего не виснет и так далее :)
          Оперативной памяти он ест — 215мб



          Ember.js
          RequireJS
          jQuery
          Handlebars

          легаси проект

          • Tallefer
            /#10496018

            И? Что пример даст? Можно еще хоть тыщу саетов накидать, что изменится-то? Кто-то немедленно пойдет их чинить? :)

            • ivanovSP
              /#10496030

              Ничего, потому что большинство людей устраивает работа современных сайтов.
              Меня как потребителя все устраивает и сейчас все лучше чем было 5 лет назад.
              Еще стоит помнить что мы пользуемся популярными сайтами бесплатно и никто никому ничего не обязан :)

              • Tallefer
                /#10496038

                Не надо за большинство говорить, особенно — будучи на противоположной стороне баррикад. %)

                • ivanovSP
                  /#10496146

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

                  Потому все же выясняется что сайты норм, а вот приложения которые написаны на Electron не норм, приводят в пример slack — я соглашаюсь.
                  Потому я привожу в пример 100 проектов в том числе Visual Studio COde — мне говорят что это исключения.

                  • ooprizrakoo
                    /#10496164

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

                    • ivanovSP
                      /#10496178

                      Ну это баг в коде какой-то у чуваков.
                      Утечка какая-то, скорей всего в анимации.

                      Ну баги везде бывают

                      • Tallefer
                        /#10496188

                        Хыхыхы, это да, баги везде, называются веб-приложения. %)

                      • ooprizrakoo
                        /#10496218

                        Плохая тенденция в том, что эти утечки уже не принято «ловить»…
                        Ну то есть: «как там, у 95% пользовательских веб-сессий страница не успевает выжрать всю память? Тогда наплюйте на рефакторинг, пилите следующую фичу».
                        Аналогично нехорошей с моей т.з. тенденцией идет утяжеление среднего веса веб-страницы там, где это это не надо.
                        Титульная страница Хабра у меня сейчас весит 3.4Мб. Из которых 1.7 Мб весит картинка из топика про Unreal Engine. «Мобильные пользователи? конечно сайт оптимизирован под мобайл! Вес сайта? Да какая разница, во всем мире сейчас у всех пользователей безлимитный 4G !»
                        Ну, и так далее ворчать хочется… За без малого 20 лет, что я сижу в инете, скорость моего канала связи увеличилась примерно в 2000 (две тысячи) раз, а скорость загрузки «среднего сайта» — ну, раза в два наверное, или около.

                        • Tallefer
                          /#10496346

                          Мне регулярно приходит в голову мысль — что было бы, если бы юБлок включил резалку тяжелых медиафайлов по умолчанию? Там стоит изначально граница в 50 кб, при таком режиме ускоряется много сайтов, например, хабр грузится гораздо быстрее, особенно статьи с тонной фоток, при этом мелкие овотарки и стрелки всякие не теряются, как и легкие пнг со схемами и текстом. :)

                  • Tallefer
                    /#10496174

                    Просто никому не надо это. :) Я могу скинуть из позавчерашнего камента, но я уже сказал — это бессмысленно, ни к чему не приведет, так как найдутся новые отмазки и так по кругу. Все ведь в курсе, что веб тормозной, просто привыкли думать или говорить, что им норм.

                  • andreymal
                    /#10496794

                    Visual Studio COde

                    Я ранее писал, что VS Code хавает полгига оперативы сразу же после первого запуска, ещё до открытия какого-либо проекта. Так что нет, он не исключение, а такое же электроноговно как и Slack :)

                    • ivanovSP
                      /#10498150

                      VS Code = 300 МБ занимает.
                      А вы сравнивали с другими IDE?
                      Все тоже самое))

                      • andreymal
                        /#10498160

                        А вы сравнивали с другими IDE?

                        Sublime Text 3 при открытом проекте с кучей питоновых плагинов — 140 МБ. Далеко не то же самое.

    • mxms
      /#10495806

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

      • ivanovSP
        /#10495846

        Почему я не жалуюсь что современные игры требуют 8 или 16 ГБ ОЗУ, я либо иду в магазин их покупать, либо играю в Mario.
        Почему я не жалуюсь что у меня лагает комп, если я запущу 40 процессов Photoshop? (а потому что я понимаю что это глупо делать)


        Никто вам ничего не обязан, тем более бесплатно, у вас всегда есть альтернатива.
        Либо подстаривайтесь либо берите альтернативу.
        Вы ничего не поменяете, таких недовольных людей как как вы — около 1-5% во всем мире.

        • Tallefer
          /#10495858

          Ну, тут 40 фотошопов, в моей ветке 100, но не суть… Так почему же тогда браузер запускает «40 фотошопов» в виде вкладок, если это глупо? :3

          • ivanovSP
            /#10495882

            Открыл 10 вкладом Microsoft, вышло около 600 мб памяти.
            умножаем на 4 получаем примерно 2.4 ГБ за 40 вкладок.
            Сейчас вы скажете подонки, но дело все не в веб разработчиках, это не программисты Microsoft Такие тупые что допустили утечку памяти, это браузеры вас избаловали.
            Хотите я подскажу вам как сделать так что бы 40 вкладок microsoft.con Занимали около 50 оперативной памяти? Это можно сделать очень легко, только вот придется убрать оптимизацию браузера, теперь после каждого перехода на вкладку вам придется отправлять запросы на сервере заново.(т.е. все сайты будут выгружаться из памяти)

            • Tallefer
              /#10495886

              Опять же, не понимаю, о чем спорим, кажется — все всё понимают, полное согласие и гармония. %)
              Хотя насчет эдакой «оптимизации» я бы поспорил…

              • ivanovSP
                /#10495938

                ну тут да, есть люди которые до сих пор жалуются что для использования Yandex карт нужен Android на телефоне и эти люди идут против системы и используют бумажные атласы за 250 рублей :)

                • Zenitchik
                  /#10495966

                  Я печатаю карты на бумаге. Тогда с ними можно работать, а не только смотреть.

                • Tallefer
                  /#10496020

                  До сих пор с собой атлас, никогда не подводил, открывается за 5 секунд, не тормозит. %)

                  • ivanovSP
                    /#10496042

                    Мельницы во дворе нет? для выработки электричества.

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

                    • Tallefer
                      /#10496046

                      С интернетом проблемы ВЕЗДЕ, если он не проводной. %) Хотя и с проводным тоже бывают. Просто люди привыкли жрать что дают. Но это мы уже обсудили выше. :)

                    • Zenitchik
                      /#10497064

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

        • mxms
          /#10495916

          Вы, к сожалению, не поняли смысла моего поста. Попробуйте ещё раз.

    • sshikov
      /#10495836

      Не очень понятно, каким образом wasm сможет сделать то, что вы от него ждете? legacy нужно выбрасывать? Что именно выбросить, IE как браузер? Ну так это во-первых, не зависит от нас с вами (это пользователи почему-то сидят на старых версиях), а во-вторых, wasm-то тут каким боком?

      • mitinsvyat
        /#10495842

        Я кстати не понимаю. В чем проблема прокидывать все браузерные апишки в WASM?
        Вроде, к этому все едет.

        • sshikov
          /#10495848

          Погодите. Я вот видел недавно, что поддержка самого wasm браузерами где-то на уровне 58%, что очень низко. Поясните сами, какие проблемы вы пытаетесь решить при помощи wasm, если он сам пока не в релизе и не поддерживается у львиной доли клиентов?


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

          • mitinsvyat
            /#10495874

            Ну все правильно, что все потом. Ну со временем можно будет тоже самое делать, что на js. Ну и все.

          • mitinsvyat
            /#10495876

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

          • mitinsvyat
            /#10495878

            То, что народ сейчас народ может рисовать гуи через канвас, не означает что это его задача.

          • mitinsvyat
            /#10496894

            Вообще, я часто слышу от людей, что WASM решает какие-то другие задачи, но не разу не услышал какие именно. Кто-то из них читал вот это?
            webassembly.org/docs/high-level-goals
            А какие там фичи хотят внедрить?
            webassembly.org/docs/future-features
            То, что там пишут — это очень круто. С помощью WASM можно будет писать хорошо засендбокшеный код, который будет запускаться не только в браузере, и люди смогут писать на подходящем для себя языке, а не быть вынужденными запускать транспилятор.
            На счет legacy: большинство разработчиков браузеров давно додумалось до автоматических обновлений своих браузеров, и вообще крайне не надежно не обновлять такую вещь как браузер, потому что в открытом доступе лежит большое количество описаний дыр для ишака и чего хотите. Можете их использовать, чтобы обновить им браузер.
            www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-9900/Microsoft-Internet-Explorer.html

            • Zenitchik
              /#10497076

              большинство разработчиков браузеров давно додумалось до автоматических обновлений своих браузеров

              Вы о чём-то не том думаете. legacy — это практически синоним IE.


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

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

              • mitinsvyat
                /#10497168 / -1

                Я понимаю, что для вас важно legacy oriented programming, но что-то тут не так, вам не кажется? Просто в вас вбито, что вот буду до последнего поддерживать эти старые браузеры. Но это вообще не всем важно, только некоторым (ты о них подумал, или для тебя фронтендер=хранитель легаси традиций?). Вконтакт давным давно посылает пользователей, которые браузер не обновили. Между тем появляется в браузерах кучу вещей, которые не имеют обратной совместимости. И ты НИЧЕГО не говоришь по сути в их сторону. А WASM сразу в штыки воспринимаешь.

                Вам не кажется, что почти никто из тех, кто не принимает WASM, вообще ничего о нем не читал хотя бы из официальных док или они просто боятся представить, что когда-то можно будет иметь хороший бинарный формат?

                Может ты до сих пор long polling используешь вместо вебсокетов или совсем не используешь local storage, а пытаешься в куку все запихать? А знаешь, еще бывают сайты, которые по законодательным требованиям должны работать без JS. Может ты и таких пользователей поддерживаешь?

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

                • Zenitchik
                  /#10497260

                  для вас важно legacy oriented programming

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


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

                  Нет, это в моих клиентов вбито "я не буду обновлять браузер своим сотрудникам ну пока совсем совсем не прижмёт". А клиенты — толстые и платят хорошо.


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

                  У Вконтакта клиентура такая, на которую можно плюнуть и забыть. А вот послать, например, РЖД или "Почту России" — слегка неудобно.


                  Последующие рассуждения — это совсем не про мою работу. Сайты я не пишу и никогда не писал.

                  • mitinsvyat
                    /#10497314

                    Ну в целом разногласий как бы и нет :)
                    Вопрос скорее в том был, для чего таки создали WASM?
                    Для каких целей?

                    • Zenitchik
                      /#10497408

                      Вопрос скорее в том был, для чего таки создали WASM?

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


                      П.С: Вот будет весело, если можно будет PHP в WASM компилировать ))) Можно будет писать сервер на JS, а клиент на PHP )))


                      П.П.С.: Кстати, закономерное продолжение — аналог WASM для сервера.

                      • mitinsvyat
                        /#10497446

                        WASM проектируется не только для веба.
                        Он должен будет запускаться на кофеварке тоже. Мне кажется, это продолжение идей джавы, но более удачное.
                        webassembly.org/docs/tooling
                        Вот выдержка про цели:

                        Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms, including mobile and IoT.
                        А это выдерджка про языки:
                        Compilers and language virtual machines:
                        Compilers for languages which can target WebAssembly (C/C++, Rust, Go, C#) should be able to run in WebAssembly themselves, emit a WebAssembly module that can then be executed.
                        Virtual machines for languages such as bash, Python, Ruby should work.
                        Virtual machines which use a just-in-time compiler (JavaScript VMs, luajit, pypy) should be able to support a new just-in-time backend for WebAssembly.
                        Они хотят смочь запускать считай ЛЮБЫЕ языки на чем угодно (я правда не допонимаю как они рантайм питона туда засунут правда). Я не понимаю как эту цель можно считать не амбициозной и классной.

                        А, еще. Я упоминал, что есть изоляция рантайма. Это очень круто. Потому что в тот же WASM рантайм ты можешь прокинуть нужные апишки через JavaScript, и этот код не сможет внезапно вызвать какой-то eval из JS, или прочитать что-то из кук. Ты просто сам задаешь, что твой модуль может делать.

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

      • beduin01
        /#10496010

        >Покажете пример такого сайта?
        Да полно. Он упомянутого LinkedIn до FaceBook. Два отличных примера упоротых сайта.

        >legacy нужно выбрасывать?
        Совершенно верно. Про поддержку IE вообще смешно слышать в 2017 году. Перестанете его поддерживать и люди перейдут на другие браузеры. Боитесь потерять сказочные 5% прибыли от клиентов которые сидят на старом говне? А не боитесь потерять 15-20-30% тех, кто с вашего сайта уйдет т.к. он будет медленно открываться, в нем будет неудобная навигация, он не будет адаптирован для людей с плохим зрением (а их куда больше чем пользователей IE) и еще 101 причина?

        Вот буквально вчера пытался открыть www.zolotoy-vavilon.ru/rostokino в FireFox у меня он не открывается от слова совсем. Оранжевая хрень загружается какая-то и все.

        >во-вторых, wasm-то тут каким боком?
        Можно будет писать на любых других языках, многие из которых проще, быстрее, логичнее чем JavaScript. А значит более эффективны по цене\качеству.

        • sshikov
          /#10496056

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


          многие из которых проще, быстрее, логичнее чем JavaScript.
          Ну, скажем прямо, на сегодня реально работающий тулчейн — это emscripten. Это вы про какой язык, тот которые проще и логичнее, C что-ли? :) И потом, в сегодняшних реалиях у wasm настолько ограниченный API, что о замене JS им говорить пока рано. Даже DOM пока нет. И GC нет — так что компиляция для многих языков, где он есть, пока под вопросом.

          Кроме всего прочего, писать на разных языках можно и сегодня. Много их, чего уж там. Десятки пожалуй. И что это реально меняет? Возможность писать на любых других языках — это вовсе не решение тех проблем, на которые вы жалуетесь. Ну вот например, сайт медленно открывается… разве причина в javascript? А уж тем более неудобная навигация, или адаптация под людей с плохим зрением или дальтонизмом? wasm — это всего-лишь переносимый байткод, по большому счету. Он этих проблем, во всяком случае непосредственно, никак не решает. И даже не собирается.

      • ivanovSP
        /#10496052 / +1

        Тут от силы 4-6 человек из 2000 понимает что такое WASM и как он работает.

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

  29. Mingun
    /#10495472

    Статья хорошая, но не без ложки дёгтя. Что-то никто из комментирующих не заметил большой логической дыры вот здесь:


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

    Простите, это как: функция загрузки не определена, но реализована очень хитро? Святым духом, что ли? А где же описание require.js, которое должно быть в этом месте? Повествование должно было развиваться так:


    1. require не определён;
    2. добавим функцию require с асинхронной подгрузкой, имитирующую работу с файловой системой;
    3. это всё работает не очень удобно, куча асинхронных запросов (читай, тормоза), поэтому давайте объединим всё в один файл, но так, чтобы исходники трогать вообще не пришлось. Тут переход к сборщикам.

    Пункт 2 в статье почему-то пропущен.

    • justboris
      /#10495488

      Вот вам пропущенное звено пункта 2: https://github.com/systemjs/systemjs


      Все как вы и описали, неудобно, тормозит, поэтому автор сразу перешел к следующему пункту

      • Mingun
        /#10495584

        Все как вы и описали, неудобно, тормозит, поэтому автор сразу перешел к следующему пункту

        О том и речь, логическая цепочка оказалась нарушенной.

        • justboris
          /#10495784

          Обязательно нужно самому наступить на грабли, рассказа о том что это больно — недостаточно?


          Ну и потом, статья не резиновая, если отвлекаться на тупиковые ветки, то не хватит времени/места на основное

          • Mingun
            /#10495800

            Эм, какое из слов во фразе «логическая цепочка оказалась нарушенной» непонятно? Ещё раз, в статье чёрным по белому написано: «поэтому такая загрузка модулей реализована очень хитро». Какая такая? Через функцию require, «которая не определена»?

          • KostaArnorsky
            /#10497860

            Замечание совершенно справедливое, мне тоже резануло. Чуть изменить на что-то вроде. «Различение реализации require были сделаны очень хитро...» и далее по по тексту, и связанность сразу улучшается.

    • mayorovp
      /#10495594

      Пропущен этот пункт потому что настраивать require.js сложнее чем webpack.

  30. p777
    /#10495474

    Если я правильно понял мысль,

    При изменении JavaScript-кода в index.js webpack-dev-server будет пересобирать свой собранный в пакет JavaScript и автоматически обновлять браузер. Это действительно экономит время, потому что можно сосредоточиться на коде, а не постоянно переключать внимание с кода на браузер, чтобы просматривать изменения.


    То это можно было делать и раньше — надо просто закрыть броузер, например Alt+F4, и сосредоточиться на коде. Но мне почему-то кажется, что в броузер все-же надо поглядывать иногда. Повеяло олд-скулом…

  31. ATwn
    /#10495516

    Да, отличная статья! Прочитав ее, понял, что все не настолько запутанно в мире Веб-разработки, как мне это раньше казалось.

  32. alexoron
    /#10495532

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

    • staticlab
      /#10495564

      Это вы по собственному опыту или просто для красного словца?

      • debounce
        /#10495652

        Костыль и синяя изолента. Это прекрасный мир IT:) Вот прямо начиная с железа всё пошло не так.

    • ivanovSP
      /#10496122

      То что вы описали про костыли — это бывает обычно в таких ситуациях:
      «Ребят а давайте возьмем JQUERY на портал биллинга, зачем нам хипстерские технологии.Архитектор в фронтенде? да вы смеетесь, во фронтенде??? джуниора нанимаем и точка! я тут власть! *Прошел год или два* — Гребанный JS(JQ) — он угробил наш проект в 2017»

      • zenkz
        /#10496398

        Да ладно! Не может JQuery угробить проект — их сотни написаны и работают. В этом плане у Angular-а или React-а шансов угробить проект больше… На самом деле проект могут угробить кривые руки… А инструмент не важен…

        Лично приходилось писать проект на старом ASP.Net WebForms всего 2 года назад, но старая технология не помешала сделать хороший продукт, хотя на чём-то более современном мог бы написать процентов на 20 быстрее…

        • Tallefer
          /#10496612

          Вот, спасибо, что хоть кто-то понимает, что для конечного пользователя нет разницы в использованных технологиях, если все делается на совесть. :)

          • ivanovSP
            /#10498236

            Можно сделать ан JQUERY мелкий проект, но крупный ты никогда не сделаешь, а если и сделаешь, то твой код будет не поддерживаемым.
            Еще раз, я не про сайты визитки говорю, для сайтов визиток современный веб вообще не нужен, там достаточно Jquery 1.1

            • musicriffstudio
              /#10498396

              выходит, семь лет назад крупных веб-проектов не существовало?

              • justboris
                /#10498484

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

                • Zenitchik
                  /#10498764

                  проектов с большим количеством клиентского кода — не было

                  Ась? А с чем я тогда работаю? Аж с 11 года? Исходников — порядка полутора мегабайт. Одностраничное приложение.


                  Да, конечно, у нас самописный MVC-фреймворк (точнее, это бывший JavaScriptMVC, но мы постепенно заменили все его части своими), но под капотом у него jQuery.

                  • justboris
                    /#10498774

                    Отдельные проекты может и были, но согласитесь, это не было таким мейнстримом, как сейчас.

                    • musicriffstudio
                      /#10498830

                      так было или не было?

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

                      Одного взгляда достаточно чтоб убедиться, ничего в качестве за 10 лет у большинства не улучшилось.

                  • ivanovSP
                    /#10498832

                    А можно ли в вашем проекте заменить всех людей и нанять новых, смогут ли они разобраться в коде?
                    Или как всегда, от 1 человека, разрабатывающего CORE фреймворка будет зависеть жизнь всего предприятия))

                    • Tallefer
                      /#10498886

                      Вся суть современного веб-дева! Теперь технологии оцениваются не качеством конечного результата, а доступностью опции «уволить всех веб-макак и нанять новых». :3

                      • Zenitchik
                        /#10498904

                        Мы макак не держим. Из-за чего меня и не любят на хабре.


                        (Правда, почитав на хабре же статьи про подводные камни с нулабельными переменными в C#, я понял, за что программисты на других языках так ненавидят JS. Мы то с нулабельными переменными и всеми сопутствующими неприятностями (а ещё — с многими другими неприятностями) — живём).

                      • ivanovSP
                        /#10499014

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

                    • Zenitchik
                      /#10498892

                      У Вас ложная дихотомия.


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

                      Или как всегда, от 1 человека, разрабатывающего CORE фреймворка будет зависеть жизнь всего предприятия))

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


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

                    • zenkz
                      /#10499238

                      Мне смешно, когда в защиту любого JS-framework-а против in-house решения выдвигают аргумент про «всех уволить и нанять новых». Попробуйте лет через 5-7 найти специалиста по 1ому Angular-у… Это то же самое, что сейчас искать разработчиков под FoxPro или Delphi… Так что преимущество неочевидное.

                      • ivanovSP
                        /#10499714

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

                        Про Delphi я писал, опять таки, это проблема того, кто рулит проектом.

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

        • ivanovSP
          /#10498234

          Вы просто не писали ничего сложней сайта визитка, да и вряд ли вы вообще занимались разработкой на JS.
          На JQUERY не реально поднять крупную SPA что бы ее можно было поддерживать и расширять, без современного фронта нет смысла вообще лезть в крупные проекты.

          Сейчас вы скажете что SPA это хипстерство конечно же и нужно брать PHP с его файловой шаблонизацией, а JS генерировать через PHP(тут может быть любой язык)



          • zenkz
            /#10499096 / +1

            Да ну! Как разработчик Enterprise-решений для крупных компаний, в том числе и на JQuery, могу сказать следующее:
            На JQuery можно написать что угодно — очень гибкая и удобная библиотека сэкономивая кучу времени разработки до появления всяких ангуляров. В том числе можно написать SPA, если это необходимо. Конечно сейчас уже в чистом виде очень редко применяется, но это не уменьшает её достоинств. Вот сейчас осваиваю Vue.js, т.к. вижу преимущества его использования (в отличии от React-а и Angular-а) — но это личные предпочтения — никому не навязываю…

            Я не скажу, что SPA — это хипстерский подход, но в некоторых случаях его прменение неоправдано. Если у вас при переходе от странице к странице меняется 80% содержимого, то SPA вам нафиг не нужен. Другое дело, если у вас есть одна страничка в приложении на которую завязан весь бизнес процесс и логика этой страницы довольно сложная. Тут SPA оправдан. А ловить гемморой с маршрутизацией и прочими проблемами SPA ради создания сайта-визитки я бы не стал…
            Кстати крупный проект можно написать с минимальным использованием JS — взять к примеру ASP.Net MVC для этих целей.

            • Tallefer
              /#10499594

              А можно вкратце про момент с вью против остальных? В чем видятся плюсы?

              • zenkz
                /#10499614

                Нравится удобное решение для компонентов. Т.к. используются стандартные html теги (script, style), то это означает подсветку синтаксиса в редакторах + js, html, css компонента в одном файле. Можно работать без использования пакетных менеджеров и прочих наворотов, т.е. просто подключив js скрипт. А в остальном очень похоже на ангуляр, но проще и удобнее.

                • Tallefer
                  /#10499630

                  Спасибо. А если сравнить с жуквери, большой прогресс?

                  • zenkz
                    /#10499638

                    Да, прогресс большой. То, что требует большого объема кода на JQuery, тут делается почти без усилий. Плюс двухсторонний байндинг, мощные шаблонные инструменты (как v-if, v-for и другие). Конечно всё это есть в Angular, Knockout.js, но в Vue это смогли реализовать как-то проще и удобнее. Что самое интересное, что производительность не сильно пострадала. Да и порог входа ниже чем у ангуляра с реактом. (А это важно, т.к. нужно джуниоров учить и динозавров переучивать :) )

      • kekekeks
        /#10496624

        Нам вот ангулар проект угробил. Он жрал 900 мегабайт, а у 80% клиентуры были офисные компы с гигабайтом оперативки. Закопано в это всё 15 лямов в итоге. Зато SPA, рилтайм и пыщь-пыщь-звонки через webrtc.

        • staticlab
          /#10496632

          А как у вас определялись требования к проекту?

        • ivanovSP
          /#10498276

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

          А что скажете на то что мои проекты жрут по 250 мб оперативки?
          Я вам могу минимум 20 проектов скинуть от других компаний.

          • kekekeks
            /#10498770

            А что скажете на то что мои проекты жрут по 250 мб оперативки?

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

            • kekekeks
              /#10498772

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

              • Tallefer
                /#10498894

                Вот да. Но не просто «можно», а «можно дешево, быстро, молодежно». :)

              • ivanovSP
                /#10499832

                Electron?
                Знакомый недавно запилил клиент(админку) для сайта на десктопе, весит 200мб.
                оперативки занимает 30мб.

                Директору лень было в браузер заходить. хотел заходить и управлять всем через MAC OS приложение.

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

                • ivanovSP
                  /#10499868

                  И он сделал это бесплатно.(либо какие-то копейки, ибо WEB версия админки уже была готова)
                  А что можете вы этому директору предложить?
                  сказать что нужно поднимать новый отдел и выделить 100 000 рублей?
                  Сделать ярлык на сайт?

                  Да, это не по поцански, лишние байты и т.д.
                  Но заказчика все устроило (экономия сроков/финансов + удобство)

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

          • zenkz
            /#10499106

            А вы правда считаете, что веб-приложение должно жрать 250 Мб?

            Мне кажется если выходит за 100 Мб, то уже что-то не то в проекте.

            • ivanovSP
              /#10499816

              Зависит от проекта, у меня в проекте очень много SVG элементов.
              Рисую я их не вручную, а через готовые библиотеки. (d3.js hightCharts)

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


              • ivanovSP
                /#10499820 / +1

                Если будут задача: Слушай, у нас есть диназавры, нужно под них одну штуку написать, помни что там 95% старого железа.
                Конечно же я не стану брать все эти фейрморки и т.д.)

                Вы понимаете как работает программист.
                Но вы не понимаете как работает бизнес.

                Я не буду писать целенаправлено под диназавров, например под IE9,10(либо чувак с Nokia на opera mini), если этого нет в ТЗ
                Если есть, то я беру +50% к заказу условно.
                Потому что мне нужно писать вместо 10 строк — 100 строк грубо говоря.

  33. Electrohedgehog
    /#10495574

    Недавно на конференции докладчик писал код под андроид. Он копировал функции по 10-15 строк и извинялся, что нет времени вбивать руками, так как это не веб и после каждой правки потребуется полминуты на сборку и каждая правка опечатки будет стоить этой самой пересборки.
    Я почти заплакал, ведь мой самое маленькое приложение собирается две минуты из за необходимости собирать в бандл не только один файл но весь чертов ангуляр с плагинами и зависимостями. Ускоряем разработку, пишем на кофесрипте, используем транспиляторы и минимизатор. Светлое, мать его, будущее.

  34. ameli_anna_kate
    /#10495610

    Было интересно прочитать статью, правда в моем проекте gulp/babel.
    Интересно будет почитать, как вы организуете работу с полученными от сервера данными, какой-нибудь шаблонизатор или фреймворк?

    • staticlab
      /#10495638

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

  35. EviLIvan
    /#10495654

    Может было выше, но почему в статье webpack запускается не просто:


    webpack index.js bundle.js


    А из node_modules:


    $ ./node_modules/.bin/webpack index.js bundle.js


    Запускать вебпак не из модулей, куда проще.

    • mayorovp
      /#10495712

      Чтобы запускать его просто — надо или установить его глобально, или запускать через npm.

  36. Norbeel7
    /#10495656

    Непосредственно Каха тоже поддерживает js

  37. PavelVershinin
    /#10495658

    Очень полезная и наглядная статья.
    Большое спасибо, от динозавров!

  38. Foxbator
    /#10495660

    Объясните динозавру зачем в бэкенде javascript

    • ivanovSP
      /#10495670

      javascript уже в мобильных приложениях и десктопе.
      Экономия на сотрудниках.
      Позволительно когда проекты не сложные и высокие знания особо не нужны.
      Не знаю какой привести пример, но если вы делаете что-то типа: «Показать записи, сгруппировать, вывести комментарии, показать среднее число постов в сутки, отправить данных на клиента, добавить, отредактировать», то вам не нужен крутой бекендер, там особо много ума не нужно, подойдет и фронтендер со знаниями бека.

      Если это что-то реально серьезное нужно сделать на беке, то такой разработчик уже будет плох.

    • Terras
      /#10495696

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

      Зачем node.js пихают на другие типы проектов — это уже глупый хайп по типу: «А давай на Java/SpringMVC будем делать сайты визитки»

    • justboris
      /#10495790

      Вы точно под тем постом комментарий оставили?


      В статье рассказывается только о фронтенде, коде, который запускается в браузере.

  39. maolo
    /#10495662

    Смотрю, в репозитории gulp'а с июля месяца вообще никакого движения — нет перспектив?
    Webpack — это полная замена gulp'у?

    • mayorovp
      /#10495718

      Нет конечно же. Просто в большинстве проектов кроме webpack ничего не нужно.

  40. alexander_8901
    /#10495782

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

  41. tushev
    /#10495948

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

    • staticlab
      /#10495968

      Фронтенд должен собираться в отдельную директорию, которую уже видит веб-сервер. Соответственно, node_modules, src напрямую нигде светить не надо.

  42. WebmasterW3S
    /#10496080 / -1

    Я так и не понял — а зачем это всё надо? Менеджеры пакетов, серверный яваскрипт, коффескрипт… что это за бред пьяных наркоманов? Нормально так… ща какой-то яваскриптик там у себя обновится, а у меня из-за этого весь сайт полетит. Если мне понадобится обновление какой-то библиотеки — мне не сложно будет вручную заменить файлик на сервере. Гораздо сложнее настраивать это всё бесполезное говно.

    • staticlab
      /#10496090

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

  43. AirLight
    /#10496322

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

    • staticlab
      /#10496596

      Это хороший вопрос. К сожалению, moment пытается грузить в ноде локали самостоятельно, в результате webpack вынужден импортировать их все. Один из возможных вариантов решения — прописать в конфиге:


        plugins: [
          new webpack.ContextReplacementPlugin(/moment[\/\\]locale$/, /en|ru/)
        ]

      • AirLight
        /#10499384

        Да, спасибо, бандл уменьшился с бешеных 247 Кб, до 62 Кб.

  44. m0Ray
    /#10500072 / -1

    Боже, какой ужас. Слава ЛММ, что я вовремя бросил заниматься фронтендом.