Подключение import в js коде

[Malleys]

То, что вы рекомендуете оправдано в разработке современных разработок откидывая старые версии браузеров

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

Когда то import небыло, тем более parcel.

Да, не было import, однако это не значит, что нужно изобретать костыли, которые намертво прибивают ваш код к определённым инструментам, которые диктуют, как вам писать код. Был Google Closure Compiler, который вы можете использовать до сих пор.

Если постоянно думать о браузерах 5-ти летней давности и старше, то почти ни чем нельзя пользоваться.

В принципе можно! Если в пишете код, совместимый со стандартами, то его вполне можно преобразовать при помощи Google Closure Compiler, Babel, Webpack и пр. Однако если придерживаться точки зрения Poznakomlus, который предлагает переписать весь код под RequireJS, то он не понимает того, что он намертво привязан к RequireJS. Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler, а если и он мне вдруг не понравится, то я могу легко его заменить на webpack и т. д. А ещё есть rollup.

RequireJS works in IE 6+, Firefox 2+, Safari 3.2+, Chrome 3+, and Opera 10+.

Т. е. я вполне могу написать код, который работает в IE 5 или в Netscape Navigator, но благодаря RequireJS он перестанет там работать?! У инструментов, которые я вам перечислил, таких проблем нет!

это да, но веб-компоненты в пример мы ждем очень долго

Давай ты не будешь свой ожидания переносить на всех! Веб-компоненты уже поддерживаются во всех современных браузерах — https://caniuse.com/#feat=custom-elementsv1. Ещё о них — https://www.webcomponents.org/

мы ждем очень долго иначе большинство фреймворков пошло [бы] в утиль

Совсем нет! Например, веб-компоненты никак не заменяют работу с виртуальным DOM.

вы спрашиваете процент старых браузеров, я привел данные из документации это минимальные версии браузеров

Версии, которые тут же увеличатся, как только вы начнёте использовать нечто, чего нет в супер старинных браузерах. (Например, работа с <canvas>, SVG, шрифтами и пр.)

И почему ИЕ6, а не ИЕ4 или НетскэйпНавигатор

У него очевидно в детстве ничего кроме IE 6 не было. Мне например сразу не понравился IE 8 (или 7?), поскольку даже на моём первом телефоне (Sony Ericsson W580i) работало SVG и CSS применялся правильно и JavaScript работал, а IE часто показывало только пустую белую страницу с обрывками текста!

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

Я к ничему такому не принуждаю себя! Для меня всегда была важна поддержка браузерами стандартов, а IE это делал очень-очень плохо. Даже 10 лет назад были альтернативы, которые делали это лучше, чем IE. Сегодня нам не нужно оглядываться на эту ошибку Microsoft. Люди сегодня практически его не используют, поскольку в нём большинство сайтов не работает, да и устройства и ОС заменяют на новые, где его уже нет!

[Aetae]

Ну представьте, если бы производители игр (или более нужных программ) ориентировались на Вин-95 на Пентиуме-4?

Сейчас производители игр ориентируются на консоли. Которые всегда устаревшие по характеристикам и с геймпадами как основным устройством ввода, что, соответственно, тормозит развитие графония и примитизирует интерфейсы. Увы.

[voraa]

В принципе можно! Если в пишете код, совместимый со стандартами, то его вполне можно преобразовать при помощи Google Closure Compiler, Babel, Webpack и пр. Однако если придерживаться точки зрения Poznakomlus, который предлагает переписать весь код под RequireJS, то он не понимает того, что он намертво привязан к RequireJS. Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler, а если и он мне вдруг не понравится, то я могу легко его заменить на webpack и т. д. А ещё есть rollup.

Т. е. я вполне могу написать код, который работает в IE 5 или в Netscape Navigator,

Код то вы перенесете. И то не весь. Вы уже писали про canvas, но есть еще всякие прокси, типизированные массивы (они могут быть промоделированы, но теряется главное, для чего они были задуманы - скорость). Даже классы переносятся не на 100% (например наследование от Array)
Но сайт это не только Javascript, это еще и HTML и CSS. С ними то как быть?

[Vlasenko Fedor]

Malleys, Google Closure Compiler, каим боком к import относится

Если я пишу код ECMAScript2020 и использую parcel, и вдруг оказывается, что что-то мне вдруг он не нравится, то я легко могу parcel заменить на Google Closure Compiler

Разберитесь это разные сервисы и либы. У них абсолютно разные назначения и функционал.

У него очевидно в детстве ничего кроме IE 6 не было

конечно не было, не было и IE 6. Ведь это был MK53,Специалист
У тех библиотек которые вы предлагаете есть версии совместимости(минимальные) так-же.

Я к ничему такому не принуждаю себя! Для меня всегда была важна поддержка браузерами стандартов, а IE это делал очень-очень плохо. Даже 10 лет назад были альтернативы, которые делали это лучше, чем IE. Сегодня нам не нужно оглядываться на эту ошибку Microsoft. Люди сегодня практически его не используют, поскольку в нём большинство сайтов не работает, да и устройства и ОС заменяют на новые, где его уже нет!

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

Совсем нет! Например, веб-компоненты никак не заменяют работу с виртуальным DOM.

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

Я переписывать ничего не предлагал, зачем вы сочиняете от моего имени?
Не нравится мое мнение, что скажите про 12 тысяч других. Или это тоже не аргумент?
Научитесь считатся с мнениями других. Мы все в жизни ошибаемся, в любых сферах. Но учитывать , обращать на мнения доугих стоит. Они могут быть правильными или неправильными в вашем понимании (но рассмотреть и учитывать их нужно, с вашими весами). Глядишь через какой-то промежуток времени помеяется взгляд.

[Malleys]

Вы уже писали про canvas, но есть еще всякие прокси, типизированные массивы (они могут быть промоделированы, но теряется главное, для чего они были задуманы - скорость). Даже классы переносятся не на 100% (например наследование от Array)
Но сайт это не только Javascript, это еще и HTML и CSS. С ними то как быть?

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

Далее для Poznakomlus...

Google Closure Compiler, каким боком к import относится

Самым прямым, он (почти?) полностью поддерживает синтаксис JavaScript. Да и вообще практически все такие инструменты давно уже поддерживают import.

У них абсолютно разные назначения и функционал.

У них полностью одно и тоже назначение — преобразование кода.

не стоит троллить мелкомягких, это их бизнес и им решать.

Они зарабатывают явно не из-за IE 6–8, которые они больше не поддерживают! Современный Microsoft — это совсем другое дело, а вы, что-то всё мечтаете о старом Microsoft с «хрюшами» и IE 6.

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

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

И почему виртуальный DOM должен реализован внутри веб-компонент? Разве веб-компонент не должен быть представим при помощи виртуального DOM (конечно же должен, что мы и видим, используя, например, React), как и все остальные HTML-элементы. И вообще идея виртуального DOM заключается в том, что есть некий объект o1, который описывает, как должен выглядеть реальный DOM без привязки к нему. После некого изменения появляется другой объект o2, который сравнивается с o1. Различия применяются к реальному DOM. Это один из способов изменения реального DOM, но совершенно непонятно, зачем внутри веб-компонент нужна обвязка вокруг уже существующего API.

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

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

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

И что мешает исправить? Неужто то самое «рꙋкожопіе»!

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

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

Я переписывать ничего не предлагал, зачем вы сочиняете от моего имени?

А разве там import будет работать? Нет? Ну значит придется переписать код в «говнокод», чтобы заработало! Твои призывы к использованию RequireJS как раз равносильны тому, как если бы ты так и сказал — «перепиши и заработает».

Не нравится мое мнение, что скажите про 12 тысяч других.

А что, каждое твоё мнение должно восхвалятся и высоко почитаться?

Научитесь считатся с мнениями других.

Т. е. вы ожидаете, чтобы вам оказывали почести?

Мы все в жизни ошибаемся, в любых сферах.

А это уже как некий культ Феди! Культ «Ѳеодоръ»

Они могут быть правильными или неправильными в вашем понимании (но рассмотреть и учитывать их нужно, с вашими весами).

Ещё и цензура?! Твоё священное мнение может нравиться, а может и нет, но оно никак не может быть «неправильным». Другое дело если вы захотели обманом и всякими хитростями выдать желаемое за действительное (например, «все, что вамъ нꙋжно длѧ разработки днѧ сего IE6 jQuery RequireJS Ѳеодоръ рекомендꙋетъ»), но это уже искусство.

[Vlasenko Fedor]

Malleys,
ты троль точка

[voraa]

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

Далее для Poznakomlus...
Самым прямым, он (почти?) полностью поддерживает синтаксис JavaScript. Да и вообще практически все такие инструменты давно уже поддерживают import. У них полностью одно и тоже назначение — преобразование кода.

Какие полифилы? Вы о чем? Назовите мне полифил для прокси? Назовите мне полифил для правильного наследования Array?
Какой полифил для css position:sticky; ?

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

Google Closure Compiler вообще не при чем ту. Он только сжимает существующий код без всяких преобразований, типа заменим эту функцию на две другие. (И то тут столкнулся, что свежий Compiler не справляется с новыми синтаксическими конструкциями Javascript, которые уже реализованы в Хроме)

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

Но тем не менее так делалось. Те же Promise были раньше по разному реализованы в библиотеках, прежде чем войти в язык. И всякие forEach, map... тоже были как отдельные библиотеки, прежде, чем стали стандартом API.

[Malleys]

Те же Promise были раньше по разному реализованы в библиотеках, прежде чем войти в язык. И всякие forEach, map... тоже были как отдельные библиотеки, прежде, чем стали стандартом API.

Класс Promise, методы forEach, map, filter, reduce и пр. для работы с массивами не «решают какой-то частный случай», они могут быть использованы для широкого круга задач, также они были уже реализованы во многих языках до того, как появились в JS. Такое полезно в любом окружении, включая браузер.

А VDOM — это узкая задача, что именно будет улучшено в ядре? Какой широкий спектр задач удастся решать? Какие примеры реализации в других языках программирования? Непредвзятые ответы «нет», а значит достаточно библиотеки. (Или вы мечтаете, что в ядро однажды будет включен весь NPM-регистр?)

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

Разработчики скорей всего не задумываются, что новые возможности, которые работают хорошо в новых браузерах, начинают работать там же чуть хуже (или совсем хуже и требуют больше памяти, процессорного времени) после преобразования кода в ES3. Однако возможно код ES2020, который работает в современных браузерах не преобразовывать (только минификация), или преобразовать до ES2018 или ES2016, что не так критично. А старым браузерам давать тот самый ES3. Это возможно благодаря атрибуту nomodule у элемента <script>

<script type="module" src="app.js"></script>
<script nomodule src="fallback-app.js"></script>

Поскольку все современные браузеры понимают type="module" и игнорируют скрипты с nomodule, то в них будет загружен app.js. А поскольку старые браузеры игнорируют скрипты с неправильным type и не понимают nomodule, то в них будет загружен fallback-app.js.

Какие полифилы? Вы о чем? Назовите мне полифил для прокси? Назовите мне полифил для правильного наследования Array?
Какой полифил для css position:sticky; ?

Достаточно широкий круг возможностей доступен в старых браузерах благодаря Polyfill service — https://polyfill.io/v3/url-builder/ Хотя он всё меньше нужен становится.

Если вам в проекте так критически важно «правильное наследование Array», то ведь не сложно добавить одну строчку с __proto__ в объявлении класса (__proto__ широко доступен с 2010–2013 годов) https://caniuse.com/#feat=mdn-javasc...s_object_proto

«Хочу, чтобы всё работало в IE6» выглядит как теоретический бред, который не несёт никакого практического смысла — Proxy работает во всех современных браузерах с 2015–2016 годов — https://caniuse.com/#feat=mdn-javascript_builtins_proxy Этого вполне достаточно, даже если вы обновляете браузер раз в полтора года!

position: sticky; работает с 2014–2017 годов, в основном ничего не ломается, если не поддерживается. Частное решение — position: fixed; Учитывая, что есть @supports, который поддерживается с 2013–2015 годов (https://caniuse.com/#feat=mdn-css_at-rules_supports), вы можете сделать альтернативное представление элемента для любителей старых браузеров!

А все эти ваши борьбы с системами, где по какой-то параноидальной причине запрещено обновить браузер 15-ти летней давности похожи на Специальную Олимпиаду. Сам же Microsoft активно призывает пользователей переезжать на новый Edge. https://www.microsoft.com/en-us/edge

Также может не стоит исключать SSR, но всё зависит от того, что вы делаете. Например, если делаешь что-то с использованием WebGL, как не крути не трансформируй код, и не придумывай фантастические полифилы, а WebGL в первую очередь должен поддерживаться!

Google Closure Compiler вообще не при чем ту. Он только сжимает существующий код без всяких преобразований, типа заменим эту функцию на две другие. (И то тут столкнулся, что свежий Compiler не справляется с новыми синтаксическими конструкциями Javascript, которые уже реализованы в Хроме)

Может всё зависит от того, с какими аргументами вы его запускаете? В первую очередь он для стандартного JS. Вам нужно съездить в Вавилон для экспериментов.

[voraa]

Достаточно широкий круг возможностей доступен в старых браузерах благодаря Polyfill service — https://polyfill.io/v3/url-builder/ Хотя он всё меньше нужен становится.

Прокси даже с Бабилоном не поддерживаются https://kangax.github.io/compat-table/es6/

Это возможно благодаря атрибуту nomodule у элемента <script>

Т.е. писать двойной код. Отдельно для старого, отдельно для нового.
Но если одинаково хорошо работает и там и там, то зачем нужен новый?
Вот только что наткнулся, что оказывается даже edge 18 не поддерживает в css rgba(0,0,0,50%). И никакой бабилон, или вебпак тут не помогут. Перетряхивать весь код и приводить к какому то старому варианту. А зачем тогда новый нужен?

Если вам в проекте так критически важно «правильное наследование Array», то ведь не сложно добавить одну строчку с __proto__ в объявлении класса (__proto__ широко доступен с 2010–2013 годов) https://caniuse.com/#feat=mdn-javasc...s_object_proto

Это не спасает. Что я не делал наследования и с помощью __proto__?
Многое наследуется, но a[i] = x не изменяет length, если i больше.
Такое возможно только при наследовании с классами. Там немного другой механизм.

А все эти ваши борьбы с системами, где по какой-то параноидальной причине запрещено обновить браузер 15-ти летней давности похожи на Специальную Олимпиаду. Сам же Microsoft активно призывает пользователей переезжать на новый Edge. https://www.microsoft.com/en-us/edge

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

Хуже когда и совершенно новые браузеры не следуют стандартам и творят хрен знает что. Тут уже больше недели трахаюсь с FF (совершенно свежая 72 версия) что они там с pointer events творят!
Тут прочитал на бугзиле их переписку (месячной давности) по этой теме (Правда она наверно относится к мобильной версии). Так они там с удивлением обнаруживают, что оказывается Хром (и даже Едж 18) производят захват событий! Оказывается! А стандарты и спецификации не дано посмотреть? Потом обсуждения про то, что НЕОЖИДАННО вылетает событие pointercancel.... Так у меня и на десктопе в 72 версии FF тоже самое! А десктопная версия в caniuse отмечена как полностью рабочая. Начинаю хренеть с поделки под названием firefox.

[Malleys]

Прокси даже с Бабилоном не поддерживаются

Так всё правильно, это реализуется на уровне движка. Смотрите правее в той же таблице — поддерживается во всех последних браузерах. Не поддерживается в Babel — значит он никак не меняет такой код, что и не нужно поскольку так и так поддерживается во всех браузерах.

Т.е. писать двойной код. Отдельно для старого, отдельно для нового.

Нет! Скорей разные сборки — ES2020 и ES3 + может плагины и полифилы и затычки и скрывалки.

даже edge 18 не поддерживает в css rgba(0,0,0,50%).

Перетряхивать весь код

Stylus или SCSS в помощь

Это не спасает. Что я не делал наследования и с помощью __proto__?
Многое наследуется, но a[i] = x не изменяет length, если i больше.
Такое возможно только при наследовании с классами. Там немного другой механизм.

Синтаксис классов — это синтаксический сахар для функции и prototype. Никакого особого механизма нет. Вот, например...

{
	class ArrayFiller extends Array {
		constructor(count, filler) {
			super(count);
			this.fill(filler);
		}
		/* остальные методы */
	}

	const af = new ArrayFiller(5, "a");
	console.log(af.length); // 5
	af[10] = "b";
	console.log(af.length); // 11
	af.length = 1;
	console.log(af); // ArrayFiller ["a"]
	console.log(af instanceof ArrayFiller); // true
}

равносильно...

{
	function ArrayFiller(count, filler) {
		var af = new Array(count);
		af.__proto__ = ArrayFiller.prototype;
		af.fill(filler);
		return af;
	}

	ArrayFiller.prototype = {
		__proto__: Array.prototype,
		constructor: ArrayFiller
		/* остальные методы */
	};

	var af = new ArrayFiller(5, "a");
	console.log(af.length); // 5
	af[10] = "b";
	console.log(af.length); // 11
	af.length = 1;
	console.log(af); // ["a"]
	console.log(af instanceof ArrayFiller); // true
}

Такой же способ использовался в Chrome DevTools для наследования от HTMLDivElement и пр. HTML-элементов.