company_banner

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

https://medium.com/@peterxjang/modern-javascript-explained-for-dinosaurs-f695e9747b70
  • Перевод


Если вы не изучали 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 может быть тяжело работать, потому что он продолжает быстро меняться и развиваться. Но даже если иногда это похоже на изобретение колеса, быстрая эволюция языка помогает продвигать инновации вроде горячей перезагрузки, линтинга в реальном времени и отладки в режиме «машины времени». Сегодня интересно быть разработчиком, и я надеюсь, что эта статья поможет вам спланировать свой собственный путь.


Mail.Ru Group 772,97
Строим Интернет
Поделиться публикацией
Похожие публикации
Комментарии 502
  • +4
    Следующий шаг — это полная поддержка импорт-синтаксиса es7 в node.js и webpack. Тогда всё будет окончательно изоморфно.
    • 0
      Ну + бабель и в ноде ты можешь писать фул es6
      • –1
        Какое-то это тяжелое извращение транспайлить бабелем серверный код… :(
        • –1

          При этом удивительно что достаточно полного es6 до сих пор нет даже в Firefox / Chrome. В IE нет даже arrow functions! Это при всей продвинутости их виртуальных машин, большом количестве ресурсов, контрибьюторов — казалось бы дело нескольких месяцев. Такое ощущение что Javascript специально искусственно загоняют в рамки убогой кросс-трансляции, вынуждая программиста использвать огромный tool chain.


          Скажи какому разработчику Python / Java / PHP что для использования последней версии языка ему нужны кросс-трансляторы вместо нормального интерпретатора с байт-кодом, удивятся. А в мире Javascript это "норма" и даже пишутся статьи в защиту такого подхода.


          Слава Богу можно разрабатывать большие приложения в обычном ES5 без кросс-трансляции, используя Knockout.js или Backbone, да и в React тоже (хоть и сложнее).

          • 0

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

            • 0

              Что ж в этом хорошего?

              • +1

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


                Хотя я не удивлюсь если в удивительном мире Java для Android однажды кросс-транслятор таки появится.

                • +1
                  Хотя я не удивлюсь если в удивительном мире Java для Android однажды кросс-транслятор таки появится.

                  Уже есть, вроде: https://github.com/orfjackal/retrolambda


                  UPD. Ого, там кроме retrolambda есть целый зоопарк для перекомпиляции в более старые версии Java.

                  • 0

                    Кажется, Lombok работает как транспилятор. Например, позволяет в обычном коде на Java использовать ключевое слово val (аналог var из C#). Причём, может использоваться как compile-time в "огромном тулчейне", так и просто для трансформации кода.

              • +3
                При этом удивительно что достаточно полного es6 до сих пор нет даже в Firefox / Chrome.

                Kangax говорит, что поддержка ES6 в FF/Chrome — 97%, не хватает, фактически оптимизации хвостовой рекурсии и импортов. Без первого вполне можно обойтись, для второго нужно или использовать бандлеры, или склеивать вручную. Тем не менее, разработчики хотят использовать и фичи ES7+ и/или типизацию, что без транспилятора уже никак не сделаешь. А призывы не транспилировать ниже ES2015 слышны давно. Может быть, кто-то из комментаторов уже такое практикует.


                В IE нет даже arrow functions!

                Так IE уже не развивается. А в Edge поддержка есть.


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

                Так код открыт. Покажите этим криворуким разработчикам мастер-класс.


                Такое ощущение что Javascript специально искусственно загоняют в рамки убогой кросс-трансляции, вынуждая программиста использвать огромный tool chain.

                Масоны, иллюминаты, инопланетяне или русский след?

                • 0

                  Хром уже зарелизил ES6 модули, в FF и Edge они под флагами, а хвостовая рекурсия вроде как об имплементации, а не синтаксисе.

                • 0
                  Такое ощущение что Javascript специально искусственно загоняют в рамки убогой кросс-трансляции, вынуждая программиста использвать огромный tool chain.

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

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

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

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

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

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

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

                    • –1
                      И я поддержу — недавно нужно было написать небольшую админку и я по старой памяти захотел использовать бутстрап.
                      Через 20 минут ковыряний у меня были установлены node.js, npm, webpack, bower (зачем-то), гит показывал 300+ добавленных файлов, а я не понимал, нафига мне всё это — ведь я хотел только bootstrap.min.js
                      • 0
                        гит показывал 300+ добавленных файлов

                        А в .gitignore вы их добавить не пробовали? :-)

                        • 0
                          Конечно же я добавил node_modules в .gitignore и все стало хорошо.
                          Но до того, как я это сделал я был удивлен количеством файлов, которые были добавлены ради bootstrap.min.js, который был мне нужен.
                          • +1

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


                            Если бы bootstrap поставлялся без исходников — этот сценарий был бы невозможен.


                            Хотя я бы на их месте просто предоставлял два пакета вместо одного (bootstrap и bootstrap-source к примеру).

                            • 0
                              Мне кажется, что вы не очень поняли мой комментарий.
                              Я не критикую существующие методы и не говорю, что те 300 файлов были бесполезны. Просто я пропустил мимо себя новинки последних 5ти лет разработки на фронтенде и для меня переход от старой парадигмы с включением кучи своих файлов и локальных библиотек к сборке файлов при помощи бандлера и диспетчера пакетов был слишком резким — я слишком удивился количеству файлов в node_modules и не очень понимал их назначение.
                              Ваш же пример раньше решался тем, что программист сначала включал some_framework.css, а после него включал my_own_styles.css, в котором переопределял все интересующие его классы. А о такой штуке как less и переменные в css я до недавнего времени не слышал =)
                              Уж простите нас — динозавров =)
                              • +1

                                Так я потому и рассказываю...


                                Ваш же пример раньше решался тем, что программист сначала включал some_framework.css, а после него включал my_own_styles.css, в котором переопределял все интересующие его классы.

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

                                • 0
                                  Ваш же пример раньше решался тем, что программист сначала включал some_framework.css, а после него включал my_own_styles.css, в котором переопределял все интересующие его классы.

                                  Только вот переменные могут объединяться в выражения. Например, для расчёта правильных отступов или других размеров. Также от базовых цветов (например, кнопки — синие #303F9F, а фреймворк расчитает цвет при наведении: светлее на 10%, и цвет при нажатии: темнее на 10%. В случае ручного переопределения потребуется внимательно переопределить все стили, что муторно и чему ещё часто мешают каскады.

                                  • 0
                                    Именно для этого году этак в 2008 я писал гем для RoR, который парсил все мои css-ки и приводил все подобные значения к единому знаменателю. В основном это была борьба (неравная) с em, но и цвета и прочее тоже порой попадались =)
                                    Эх, молодость =)
                                    • +2

                                      Боюсь вас расстроить, но году в 2008 в Ruby уже был гем SASS. Наверное, не будет большой ошибкой сказать, что мода на транспиляторы для JS зародилась благодаря CoffeeScript из той же экосистемы Rails.

                      • +3
                        Отличная статья, такую бы мне пару лет назад — страданий в моей жизни было бы во много раз меньше:)
                        • +3
                          Статья как раз для меня. Очень вовремя. Только начал разбираться. Спасибо, стало понятнее.
                          • +4
                            «Изначально npm создавался как диспетчер пакетов специально для node.js, среды исполнения JavaScript, предназначенной не для серверов, а фронтенда. Так что довольно странно применять его в качестве диспетчера пакетов для библиотек, запускаемых в браузерах.»

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

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

                                • +6
                                  А еще там не настроены игноры и все это уходит на GIT?
                                  не знаю что у вас там за пакеты, у меня любой крупный проект тянет за собой около 100мб node_modules модулей
                                  • 0
                                    Вот такой package.json.
                                    {
                                      "name": ".....",
                                      "version": "0.0.1",
                                      "devDependencies": {
                                        "gulp": "^3.9.1",
                                        "gulp-sourcemaps": "^2.5.0",
                                        "gulp-stylus": "^2.6.0",
                                        "gulp-util": "^3.0.8",
                                        "jeet": "^7.1.0",
                                        "nib": "^1.1.2"
                                      }
                                    }
                                    


                                    В git не уходит, конечно же.
                                    • +1
                                      У меня с вашим package.json получилось 12 мегабайт.
                                      • –1
                                        Скорей всего у парниши просто в папке фильм лежит)
                                      • 0
                                        Реальный размер папки и правда небольшой, но из-за большого количества мелких файлов, node_modules занимает на диске 3гб. Запускать дефрагметацию? :)
                                        • 0
                                          Используйте диск с меньшим размером кластера тогда.
                                      • 0

                                        -

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

                                        ну так package.json в студию, мы вам расскажем ))
                                        • 0
                                          Выше я показал package.json. Даже удалил node_modules и заново выполнил npm install. Действительно 3 Гб.
                                          • 0
                                            Вру,
                                            • 0

                                              Попробуйте свежую ноду поставить. Или возьмите вместо npm использовать yarn.

                                              • +2

                                                Меня вот что удивляет: все эти пакеты в обязательном порядке тащат тесты. Зачем оно нужно конечному пользователю?


                                                Вот к примеру, пакет es5-ext. 787 файлов, 500 Кб. Подкаталог tests 380 файлов, 113 кб.


                                                Нет, я понимаю пользу тестов при разработке. Но в "дистрибутиве" пакета на продакшене какой в этом смысл?

                                        • +44
                                          • +5

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

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

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

                                            • 0

                                              Небольшой проект на React


                                              nepbook: {master *=} node_modules neptune$ du -hs
                                              195M    .
                                          • +16
                                            необходимость искать и скачивать новые версии библиотек при каждом их обновлении

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

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

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

                                                • +4

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

                                                  • 0
                                                    Также для этого есть semantic versioning — минорные (ничего не ломающие) фиксы библиотек можно забирать автоматически.
                                                    • +11
                                                      К сожалению, то, что минорные апдейты не должны ничего сломать — еще не означает, что они на деле ничего не сломают.
                                                      • +2
                                                        При подобных опасениях разработчик указывает в package.json точную версию библиотеки.
                                                        • +1

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

                                                          • 0

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

                                                            • 0

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

                                                • 0
                                                  Поддерживаю, сам недавно с этим столкнулся. Хорошо, что зааффектило лишь небольшой участок кода, но, тем не менее, было неприятно.
                                                  • 0
                                                    В случае опасений насчет несовместимости можно указать точные версии библиотек. Зато npm избавляет вас от необходимости заливать все сторонние библиотеки в ваш репозиторий, каждый разработчик скачивает их самостоятельно посредством команды npm i.
                                                    • 0
                                                      Для этого придётся предварительно проверить что
                                                      — библиотеки которые используются в проекте указывают точную версию используемых библиотек
                                                      — библиотеки используемые в библиотеках которые используются в проекте указывают точную версию используемых библиотек
                                                      — библиотеки используемые в библиотеках которые используются в библиотеках которые используются в проекте указывают точную версию используемых библиотек
                                                      — и т.д.
                                                      • 0
                                                        Разработчики библиотек хотят проблем еще меньше, чем вы, поэтому их политику можно оставить на их совести.
                                                        • 0
                                                          представьте что вам не выплатили зарплату т.к. бухгалтерия положилась на совесть разработчиков 1С, а в последнем обновлении была ошибка. По ошибке чёто потерялось, что ж поделать. Может быть в следующем месяце исправят. Если получится то пересчитают зарплату за прошлый месяц, не получится — ну, значит пропала.

                                                          Так понятней?
                                                          • 0
                                                            Выше я писал, что можно указать точную версию библиотеки. 1с в такой ситуации не обновится.
                                                            • 0
                                                              гарантированно не обновится и не сломается из-за проблем совместимости пакетов где-то далеко-далеко в зависимостях чужих библиотек только если не обновлять.

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

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

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

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

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


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

                                                                    • 0
                                                                      Пакеты, готовые для исполнения на сервере через 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, собранные пакеты просто не хранит)

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

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

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

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


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


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

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

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

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

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

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


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

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

                                                                                Ну и зря


                                                                                cdnjs

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

                                                                                • 0

                                                                                  Нашёл разве что такое: https://github.com/jcreamer898/anvil.cdnjs К сожалению, сам anvil.js давно уже умер.


                                                                                  Есть Fletch и его форк cdnjs-fetch.


                                                                                  Может быть и что-то питоновое есть подобное.

                                                                                  • 0

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


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

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

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

                                                                            Тут дело не в npm/yarn, а в авторах конкретного пакета, которые в пакет включают и исходники, и тесты, и документацию с примерами — проще говоря включают весь репозиторий проекта, вместо его папочки dist/build.

                                                                      • –2

                                                                        Не заливать сторонние библиотеки — это мегакосяк ) Когда в ваш проект через 10 лет понадобиться внести минимальное изменение, вы не найдете процентов 50 библиотек, а те которые найдете сменят уже три-четыре мажорных релиза и не будут работать в нужном вам окружении 10 летней давности. Желание взять все и переписать оно похвальное, но денег почему-то на это не дают )


                                                                        Ну и про расчет зарплаты у вас сказочные представления ) Ситуация выглядит так: сегодня нужно сдать отчет, 1с выкатывает релиз с "последними" исправлениями, релиз ставится.


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

                                                                        • +1
                                                                          Когда в ваш проект через 10 лет понадобиться внести минимальное изменение, вы не найдете процентов 50 библиотек, а те которые найдете сменят уже три-четыре мажорных релиза и не будут работать в нужном вам окружении 10 летней давности.

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


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

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

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

                                                              • 0

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

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

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

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

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

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

                                                                            Хром может объединять несколько вкладок в один процесс.

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


                                                                      • +1
                                                                        Как минимум Slack. Вообще я немножко утрировал, но вот про полтора гига оперативы высказывались все кому не лень
                                                                        • 0
                                                                          Уже можно спокойно говорить «про любой». %) Ну или добавить Discord, если слака мало.
                                                                          • 0
                                                                            discordapp.com — попробовал, у меня работает идеально, оперативки 100 МБ.
                                                                            Что не так конкретно?
                                                                            • 0
                                                                              попробовал
                                                                              «А включать-то пробовали?» :D
                                                                              Нет, ну ладно, примем, что для вебсофта 100 мб это «идеально»… Но в реальности это достижимо только при условии «не включать». %) То есть практически не пользоваться по назначению. Как в случае с браузерами — открывать две-три вкладки за сессию.
                                                                              • +1
                                                                                Это нормальная цифра для такого сайта.
                                                                                f6.s.qip.ru/etSMzb2V.png

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

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

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

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

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

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

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

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

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

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

                                                                                          Именно так, 95% и всем норм. -_-
                                                                                          • +1
                                                                                            Понижается скорость разработки и растет цена продукта.
                                                                                            Тут конечно зависит от много факторов, например от уровня компании, маркетинга, спроса и так далее, давайте рассмотрим фрилансера.

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

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

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


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

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

                                                                                              Так я не понял… ДЛЯ ЧЕГО память покупать? %) Если все и так тянет?
                                                                                              У меня примерно такая же жестянка, но сейчас я сижу на еще более старом ноуте.
                                                                                              Кстати да, тут уже давно должны были набежать с факелами и вилами владельцы модных ноутов, где память распаяна… %)
                                                                                              • +2
                                                                                                Я вас понял, я заказчик. сделаете мне за 50-100$ приложение которое будет запускаться на Android/IOS/WIN/UNIX/WEB?
                                                                                                Срок — 1 сутки.
                                                                                                Приложение простое, нужно разбивать загруженный текст на слова и делать по ним перевод через Yandex api + из полученных слов формировать цепочку карточек и показывать их в очереди.

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

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

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

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

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

                                                                                                  А деньги работодателю приносят конечно не пользователи, а дедушка мороз.
                                                                                                  • 0
                                                                                                    Именно так и получается. %)
                                                                                                    Кстати, их может в итоге и не быть. И тех, и других.
                                                                                            • –2
                                                                                              Только вот софт такой стоить будет не 50 баксов, а 1000 баксов.

                                                                                              Почему бы? Стоимость разработки это малая доля от стоимости конечной программы.
                                                                                              Иногда бывает лучше продать 1млн копий по 100 рублей, чем 100 по 10000.
                                                                                              • +2
                                                                                                таких людей как я еще 95% на всей планете и всех всё устаревает.

                                                                                                Б#$, да откуда же вы такие берётесь-то?
                                                                                                60% на всей планете не выходили в интернет ни разу в жизни
                                                                                                Половина всех детей на планете страдает от голода.
                                                                                                я покупал 5 лет назад 2 планки по 4гб за 3500 рублей

                                                                                                Для одной пятой населения планеты это 4 месяца работать и ничего не есть.
                                                                                                Какие к чёрту 95%?
                                                                                        • 0
                                                                                          В случае дискорда нет выбора, «десктопная» версия это тот же хромиум (и процессов по ~100мб будет уже от 2).
                                                                                          • 0

                                                                                            Десктопная версия слаки или дискорда — это ровно то же самое "веб-приложение", просто в другой обёртке. Как следствие — те же самые (+на обёртку) проблемы с памятью и всем прочим.


                                                                                            P.S. Я уж не говорю о том, что дискорд просто обожает коллекционировать устаревшие копии себя, а каждая такая копия по 120 мегов. И лежат они разумеется где попало, а не в ProgramFiles.

                                                                                            • 0
                                                                                              Серьезно? Уже не стирает даже? Раньше стирал. %) Оставлял один бэкап, вроде как хром.
                                                                                              • 0
                                                                                                В \Users\%username%\AppData\Local\Discord оно живёт. Стирать приходится вручную, да. И вообще, это порочная практика — ставить софт в профиль юзера.
                                                                                    • 0

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

                                                                                    • 0
                                                                                      Видимо, речь про Slack
                                                                                      • 0
                                                                                        Не мессенджер, но, интереса ради, можете сравнить pgAdmin 3 и pgAdmin 4 по скорости работы да хотя бы на i5-2520. Оба — десктопные приложения, второе — «web»-based. Я был шокирован.
                                                                                    • +7
                                                                                      После того, как я открыл для себя vue, я боюсь открывать jQuery код.
                                                                                      • 0

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

                                                                                        • 0
                                                                                          Вы в этом желании не одиноки, но, судя по тому что никто пока не написал — это не так просто, как кажется.
                                                                                          Наиболее очевидный путь — это ORM на JS, умеющая фронтенд. Но не все хотят JS на бэкенде…
                                                                                          А еще есть PouchDB, которая синхронизируется непосредственно с CouchDB. Но вот CouchDB использовать не очень хочется, да и не всегда нужно тащить данные на клиент.
                                                                                          • 0
                                                                                            Можете написать модель на беке и сделать генератор кода для vue на основе бек-модели. Работы на пару дней.
                                                                                            • 0
                                                                                              Pony ORM вроде как предоставляет такую возможность, если я правильно понимаю требования docs.ponyorm.com/ponyjs.html
                                                                                              • 0

                                                                                                К сожалению, не правильно поняли. Самое близкое это 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


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

                                                                                          • 0

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

                                                                                            • –1

                                                                                              У вас винчестер на 640 кб?

                                                                                              • +2
                                                                                                Зачем нужен jQuery, если есть ELM? ;-)
                                                                                                • +6
                                                                                                  Я еще помню, когда такие же вопросы звучали на тему jQuery: зачем нужен такой тяжелый фреймворк, если можно все написать на чистом JS?