> Никто не разрабатывет софт который ДОЛЖЕН работать на десятках платформ. Никто не разрабатывает софт который ДОЛЖЕН компилироваться десятком компиляторов
> JS все больше и больше становится похож на это
Не было в JS ничего подобного до прихода реакта. В нем, насколько я понимаю, иммутабельность нужна чтобы реакту быстро найти изменения. То есть для того чтобы его внутренности правильно отработали. Разработчику-пользователю фреймворка она ничего кроме чувства собственной важности не дает. Поправьте, если я ошибаюсь
В плюсах для освобождения ресурсов используют деструкторы. Но даже на плюсах вы использовали goto. Switch-case не более чем легкий синтаксический сахар над goto
> не понимая до конца преимуществ иммутабельности в макромасштабе
Расскажите о преимуществах иммутабельности в макромасштабе, будте так добры
> как и setjmp и longjmp
Они как-раз специфичные. А goto — нормальная, довольно распространенная практика в Си
> либо заниматься луддизмом, и цепляться за mutable state
mutable state отличная, рабочая парадигма. Идеологи реакта прославляют иммутабельность потомучто она критична для работы реакта — это его прямое ограничение. Как только кто-то сделает «реакт без принудтельного stateless и виртуального DOMа» все забудут этот недохаскель как страшный сон.
> О, да что вы говорите. Вы когда-нибудь открывали сложный документ (с кастомными полями, заголовками, списками, картинками, графиками и т.д.), сделанный в одной версии ворда, в другой версии ворда?
Это уже не говоря уже о том, что верстать в ворде что-то сложнее реферата
это ад адский. Руки сами тянутся переделать всё в хтмл или латехе
> ES6 имеет огромную кучу классных фич, которые я хочу использовать в своем коде
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
Взять любой современный тулкит (например, WPF) и сделать из него «браузер» (кроссплатформенную загрузку и отображение кода). Будет wpf:// вместо http://
Я выучил gulp, requirejs, babel, coffescript, browserify и так далее. Typescript стал последней каплей после которой стресс стал перманентным, а душа потребовала простоты и понятности
1. Es6 еще не пришел в браузеры, а значит использовать его еще рано. Вместо этого пишите на es5. Бонус: не нужно транслировать. Выполняется тот код, который вы написали
2. Хорошее покрытие тестами > typescript. Бонус: есть тесты — нет стресса при рефакторинге
3. Js файлы в большинстве случаев не обязательно запаковывать в один. Сравните в вашем проекте скорость загрузки всех ваших js-файлов по отдельности и одного, склеенного. Вспомните о кэшировании. И, возможно, вы решите обойтись без склеивания. Бонус: исчезнет необходимость в упаковщиках и sourcemap
4. Вам не всегда нужны загрузчики. Помните о том, что глобальный environment глобален только в пределах вашей страницы, а не всего браузера. Используйте js module pattern. Пусть каждый ваш js-файл создает одну глобальную переменную с префиксом. Например projectname_mycontroller. Проблемы могут возникнуть только если в вашем проекте не менее тысячи файлов. Бонус: не нужен requirejs. Бонус2: если захотите, можете склеить всё в один файл простым cat file1.js file2.js… > app.js. Но лучше не делайте этого (см. пункт 3)
5. Jade, less и прочие. можно транслировать используя make-файл. Он создавался именно для этой цели — преобразовывать одни файлы в другие если они изменились. Но надеко не всегда в этих инструментах есть необходимость. Простой CSS очень неплох сам по себе если знать все его особенности
6. Вам не всегда нужен react или angular. Найдите минимальную библиотеку или фреймворк, достаточную для вашего проекта. Благо выбор огромен. Используйте те библиотеки, работу которых вы понимаете. Больше магии — больше стресса. Маленькие вещи можно писать на нативных DOM и events. Они уже практически одинаковы во всех браузерах.
В результате я стал менее производительным. Однако появилось полное понимание структуры и работы проекта. А вместе с тем улетучился стресс. А еще исчезла необходимость в nodejs
возможность делать произвольные графические интерфейсы, но невозможность это делать визуально и сразу видеть изменения… лучше бы были стандартные контролы и просто контент
Веб это вам не форма и пара кнопок как в десктопном/мобильном ПО. Это сложная верстка с самыми разнообразными (часто динамически подгружаемыми) интерактивными элементами. А если еще и адаптивная под множество размеров экрана. Запилить такое мышкой в GUI даже не представляю как. Недаром часто разработчики встраивают в приложение WebView если оно визуально сложнее списка с кнопками. Хотя, согласен, пара-тройка нативных контролов бы не помешала (дерево, редактируемая таблица)
и вот 2016 год — цсс и яваскрипт занимают больше места, чем сам контент, а некоторые сайты настолько криво сделаны, что падает браузер на 4х ядерном процессоре с 8гб памяти
Это косяк разработчиков, а не технологии. В виндовс есть прекрасное ПО, а есть такое, что встраивается во все щели и показывает рекламу. Это же не повод обвинять WinAPI, OLE, etc.
> Зоопарк инструментов и технологий, зачастую из говна и палок, пытающийся решить одни и те же проблемы
На самом деле зоопарк эволюционных предков и, как результат, по 1-2 (временно) победившему инструменту в каждой нише. Но никто не заставляет вас ими пользоваться. Я, например, порой люблю обмазы писать на чистом html/css/EcmaScript5, в виде один файл — одна глобальная переменная — никаких упаковщиков или загрузчиков
> Вот показатель того, насколько программисты хотели бы писать для веба, но только не касаться JS, например
Это показатель того, что браузер распространился на все устройства с экранами и являет собой универсальную открытую платформу. Никаких закрытых сторов девелоперских лицензий, и проектов 2-в-1 (java, swift) по двойной цене. Последний оплот свободы, так сказать
> Но никто эту ванильную форму не хочет ни покупать (заказчики), ни потреблять (большинство пользователей)
Пользовалелю без разницы на чем написан ваш сайт. Если заказчику надо магазин через 2 дня: тут без CMS и фреймворков никак
Вы верстаете странички для браузера
https://en.wikipedia.org/wiki/Google_Fuchsia
А на опеннете читал, что на дарт там будет UI. Ядро на Си
В Си и Паскале можно создать функцию-переменную и передать ее в качестве пареметра в другую функцию
Не было в JS ничего подобного до прихода реакта. В нем, насколько я понимаю, иммутабельность нужна чтобы реакту быстро найти изменения. То есть для того чтобы его внутренности правильно отработали. Разработчику-пользователю фреймворка она ничего кроме чувства собственной важности не дает. Поправьте, если я ошибаюсь
> не понимая до конца преимуществ иммутабельности в макромасштабе
Расскажите о преимуществах иммутабельности в макромасштабе, будте так добры
Они как-раз специфичные. А goto — нормальная, довольно распространенная практика в Си
> либо заниматься луддизмом, и цепляться за mutable state
mutable state отличная, рабочая парадигма. Идеологи реакта прославляют иммутабельность потомучто она критична для работы реакта — это его прямое ограничение. Как только кто-то сделает «реакт без принудтельного stateless и виртуального DOMа» все забудут этот недохаскель как страшный сон.
Как минимум до конца года. А там глядишь новый «стандарт» родится
Вы теплое с мяким зачем сравнваете? В браузере вы сделаете из всего перечисленного только гуй
Тогда нам срочно нужно поколение детей-индиго, способных за 2 дня освоить стэк техгологий из этой статьи
Это уже не говоря уже о том, что верстать в ворде что-то сложнее реферата
это ад адский. Руки сами тянутся переделать всё в хтмл или латехе
Да
>Они делают код понятнее, выразительнее, более поддерживаемым и т.д
Будут делать. На данный момент мы имеем неподдержиеваемый выхлоп из babel-a плюс (по словам ОПа) 100КБ полифилов
> загрузка 500 маленьких файлов намного тяжелее загрузки одного большого файла
Намного это насколько? Сами проверяли или прочитали? В моем проектике около 100 маленьких js файлов. Разница первого запуска в 1.3 раза. Разница последующих запусков отсутствует. Считаю это нормально
> Прекрасно, а потом я буду использовать другую библиотеку, которая так же решила захламить глобал
Одна библиотека — одна глобальная переменная. Обычное явлене в js
>в мир JS пришли AMD, CommonsJS, Import/Export
Import/Export еще не пришли, в том и суть. Остальные способы — страшные костыли, которые канут в лету с приходом Import/Export
> мой скрипт не будет работать, пока другой скрипт не отработал и не положил свой результат в глобальную переменную
Вы что-то делаете не так
> Насколько маленькие вещи?
Вам решать.
> Вы точно знаете когда маленькие вещи перерастут в большие?
Обычно знаю. При нормальном разбиении приложения на слои, заменить рендер с какого-нибудь mustache на react не вызывало сложностей.
Я выучил gulp, requirejs, babel, coffescript, browserify и так далее. Typescript стал последней каплей после которой стресс стал перманентным, а душа потребовала простоты и понятности
1. Es6 еще не пришел в браузеры, а значит использовать его еще рано. Вместо этого пишите на es5. Бонус: не нужно транслировать. Выполняется тот код, который вы написали
2. Хорошее покрытие тестами > typescript. Бонус: есть тесты — нет стресса при рефакторинге
3. Js файлы в большинстве случаев не обязательно запаковывать в один. Сравните в вашем проекте скорость загрузки всех ваших js-файлов по отдельности и одного, склеенного. Вспомните о кэшировании. И, возможно, вы решите обойтись без склеивания. Бонус: исчезнет необходимость в упаковщиках и sourcemap
4. Вам не всегда нужны загрузчики. Помните о том, что глобальный environment глобален только в пределах вашей страницы, а не всего браузера. Используйте js module pattern. Пусть каждый ваш js-файл создает одну глобальную переменную с префиксом. Например projectname_mycontroller. Проблемы могут возникнуть только если в вашем проекте не менее тысячи файлов. Бонус: не нужен requirejs. Бонус2: если захотите, можете склеить всё в один файл простым cat file1.js file2.js… > app.js. Но лучше не делайте этого (см. пункт 3)
5. Jade, less и прочие. можно транслировать используя make-файл. Он создавался именно для этой цели — преобразовывать одни файлы в другие если они изменились. Но надеко не всегда в этих инструментах есть необходимость. Простой CSS очень неплох сам по себе если знать все его особенности
6. Вам не всегда нужен react или angular. Найдите минимальную библиотеку или фреймворк, достаточную для вашего проекта. Благо выбор огромен. Используйте те библиотеки, работу которых вы понимаете. Больше магии — больше стресса. Маленькие вещи можно писать на нативных DOM и events. Они уже практически одинаковы во всех браузерах.
В результате я стал менее производительным. Однако появилось полное понимание структуры и работы проекта. А вместе с тем улетучился стресс. А еще исчезла необходимость в nodejs
Веб это вам не форма и пара кнопок как в десктопном/мобильном ПО. Это сложная верстка с самыми разнообразными (часто динамически подгружаемыми) интерактивными элементами. А если еще и адаптивная под множество размеров экрана. Запилить такое мышкой в GUI даже не представляю как. Недаром часто разработчики встраивают в приложение WebView если оно визуально сложнее списка с кнопками. Хотя, согласен, пара-тройка нативных контролов бы не помешала (дерево, редактируемая таблица)
Это косяк разработчиков, а не технологии. В виндовс есть прекрасное ПО, а есть такое, что встраивается во все щели и показывает рекламу. Это же не повод обвинять WinAPI, OLE, etc.
Но ведь заранее неизвестно устройство с какой архитектурой запросит ваш код. Так что интерпретатор неизбежен
На самом деле зоопарк эволюционных предков и, как результат, по 1-2 (временно) победившему инструменту в каждой нише. Но никто не заставляет вас ими пользоваться. Я, например, порой люблю
обмазыписать на чистом html/css/EcmaScript5, в виде один файл — одна глобальная переменная — никаких упаковщиков или загрузчиков> Вот показатель того, насколько программисты хотели бы писать для веба, но только не касаться JS, например
Это показатель того, что браузер распространился на все устройства с экранами и являет собой универсальную открытую платформу. Никаких закрытых сторов девелоперских лицензий, и проектов 2-в-1 (java, swift) по двойной цене. Последний оплот свободы, так сказать
> Но никто эту ванильную форму не хочет ни покупать (заказчики), ни потреблять (большинство пользователей)
Пользовалелю без разницы на чем написан ваш сайт. Если заказчику надо магазин через 2 дня: тут без CMS и фреймворков никак