либо его переписать (что возможно, но довольно геморройно, там много сложной математики)
Две тысячи строчек, покрытых тестами — у меня одноразовые скрипты-однодневки весят больше) Хотя, быть может, переписать и протестировать всё будет таки немножко геморройно, но мне со стороны кажется, что профита от этого будет больше и для вас, и для сообщества, чем от геморроя с Nashorn.
Или у вас фиак-фигак и в продакшен и некогда кого-то куда-то портировать? Тогда все разговоры вообще не имеют смысла.
Значит официально Nashorn не поддерживается, значит на этом тему можно закрыть. Topojson фактически становится не сторонней зависимостью, а вашим кодом, а его пишите на чём хотите, хоть на ES3 — проблема зависимостей снова перестала существовать :)
Алсо, не расскажете, зачем вам Nashorn? Я про него нигде никогда не слышал, и не похоже, чтобы библиотеки тестировали и в нём тоже, а не только в браузерах и nodejs. А запускать библиотеки в заведомо неподдерживаемом окружении тоже немножко ССЗБ)
У любой нормальной либы указывается список поддерживаемых браузеров. Если такого нет или вместо него отписка типа «only for modern browsers», то это плохая либа, её использование — ваша ошибка, страдайте, чо уж :)
вы можете захотеть внести в него исправления
Ни за что не поверю, что у вас это обыденность. Ни сам я не вносил исправления в чужой код, ни знакомых, занимающихся этим регулярно, нет. Но если уж очень сильно приспичит, то весь этот тулчейн нужен будет лишь до выхода релиза, в котором баг пофиксят.
Я ранее писал, что VS Code хавает полгига оперативы сразу же после первого запуска, ещё до открытия какого-либо проекта. Так что нет, он не исключение, а такое же электроноговно как и Slack :)
Разработчики Topojson заботливо прогнали всё через babel сами и залили минифицированную ES5-версию на гитхаб. И так с большинством библиотек, поэтому указанной вами проблемы не существует :)
Ну, пока что лес не столь глубокий, лично я никаких проблем с ES5 не испытываю. Существенной разницы с ES6+ нет (без трёх с половиной синтаксических сахаров жить вполне можно, а для остального есть полифиллы), это вам не ассемблер. Да и у гита куча альтернатив есть, если что)
Зачем существует области видимости, я знаю, и активно их пользую. Вопрос в другом — зачем ограничивать доступ к области видимости? Python-way с эмуляцией приватных полей через подчёркивания я считаю хорошей идеей. Нарушать инкапсуляцию не позволят громко ругающиеся линтеры (я их юзаю как любой нормальный программист, естественно), а для отладки или костылей (когда без костылей совсем никак) — вот, пожалуйста, всё открыто, лезь куда хочешь.
А если вам нужное публичное API для сторонних независящих от вас вещей — напишите им об этом в issue, или сделайте pull request
И все так сразу взяли, меня послушали и по-быстренькому запилили / приняли пулл-реквести, ага. Если бы всё так было в реальности, я бы тут не ныл про юзерскрипты. Один знакомый не-динозавр наоборот закрыл на своём сайте почти всё публичное API, несмотря на массовые протесты юзерскриптоделов, включая меня. При этом проблемы, которые ранее исправлялись юзерскриптами, исправлять, естественно, не стал.
или просто свой fork
Который будет никому не нужен. Огромное количество сайтов (включая вышеупомянутый) живёт в интернете только за счёт контента и аудитории, и если контент ещё можно кое-как скопировать (чем я старательно занимаюсь в свободное время, держа собственные копии некоторых сайтов), то аудитория будет переходить крайне неохотно, если вообще будет — пока технические проблемы не станут совсем уж невыносимыми. А будь форк сколь угодно крутым — какой в нём смысл, если народа не будет? Если разработчики отзывчивые, баги фиксятся, пулл-реквесты принимаются — проблема «замкнутого» API не столь остра, но ведь так бывает не всегда, и в моей практике «бывает» очень редко.
А для debug-а всё есть и область видимости слабая помеха.
Но помеха. Зачем эта помеха существует?
Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?
А почему я должен ставить breakpoint, если я, например, хочу просто взять и вызвать такую-то функцию такого-то модуля, не привязываясь ни к каким событиям? Пока это всё ещё звучит как костыли и неудобства.
У динозавров никто ничего обычно не заворачивает (в библиотеках типа jQuery такое бывает, а в коде самих сайтов я такое встречал очень редко), а у не-динозавров вебпак вроде бы всё сам заворачивает, если явно не пробросить что-нибудь в window. Исключения есть, но очень редки, отсюда и связь. Алсо, когда я пытался в вебпак-проекте вытащить пару модулей наружу в том числе для упрощения отладки, меня били по рукам)
Кстати ещё насчёт дебага, меня учили старательно заворачивать всё в замыкания, чтобы в «global scope» ничего не торчало, что делает отладку через консоль невозможной в принципе, а также зачастую не даёт пофиксить какую-нибудь кривоту на чужом сайте через какой-нибудь юзерскрипт (и это одна из многочисленных причин, почему я осознанно остаюсь «динозавром»)
Собственно, затем, что всем нужен mvc на фронтенде) А нужен он потому, что все хотят пилить интерактивные онлайн-приложения. А пилят их в вебе потому, что иных нормальных платформ для онлайн-приложений не существует. А не существует их потому, что все уже обмазались костылями вокруг веба (кратким описанием костылей и является данный пост) и привыкли ко всему этому. А потом простейшие мессенджеры кушают по несколько гигабайт памяти и половину ядер процессора. Вот так и живём
Две тысячи строчек, покрытых тестами — у меня одноразовые скрипты-однодневки весят больше) Хотя, быть может, переписать и протестировать всё будет таки немножко геморройно, но мне со стороны кажется, что профита от этого будет больше и для вас, и для сообщества, чем от геморроя с Nashorn.
Или у вас фиак-фигак и в продакшен и некогда кого-то куда-то портировать? Тогда все разговоры вообще не имеют смысла.
Именно. Портируйте, тестируйте и на гитхаб ;)
Значит официально Nashorn не поддерживается, значит на этом тему можно закрыть. Topojson фактически становится не сторонней зависимостью, а вашим кодом, а его пишите на чём хотите, хоть на ES3 — проблема зависимостей снова перестала существовать :)
Никакая не хрень, с гитхаба и скачано https://github.com/topojson/topojson/releases/download/v3.0.2/topojson.zip
У любой нормальной либы указывается список поддерживаемых браузеров. Если такого нет или вместо него отписка типа «only for modern browsers», то это плохая либа, её использование — ваша ошибка, страдайте, чо уж :)
Ни за что не поверю, что у вас это обыденность. Ни сам я не вносил исправления в чужой код, ни знакомых, занимающихся этим регулярно, нет. Но если уж очень сильно приспичит, то весь этот тулчейн нужен будет лишь до выхода релиза, в котором баг пофиксят.
Я ранее писал, что VS Code хавает полгига оперативы сразу же после первого запуска, ещё до открытия какого-либо проекта. Так что нет, он не исключение, а такое же электроноговно как и Slack :)
А чё, писать на чистом ES5 (опционально с полифиллами) уже запретили?)
Я-то делаю, за меня волноваться не стоит.))
И все так сразу взяли, меня послушали и по-быстренькому запилили / приняли пулл-реквести, ага. Если бы всё так было в реальности, я бы тут не ныл про юзерскрипты. Один знакомый не-динозавр наоборот закрыл на своём сайте почти всё публичное API, несмотря на массовые протесты юзерскриптоделов, включая меня. При этом проблемы, которые ранее исправлялись юзерскриптами, исправлять, естественно, не стал.
Который будет никому не нужен. Огромное количество сайтов (включая вышеупомянутый) живёт в интернете только за счёт контента и аудитории, и если контент ещё можно кое-как скопировать (чем я старательно занимаюсь в свободное время, держа собственные копии некоторых сайтов), то аудитория будет переходить крайне неохотно, если вообще будет — пока технические проблемы не станут совсем уж невыносимыми. А будь форк сколь угодно крутым — какой в нём смысл, если народа не будет? Если разработчики отзывчивые, баги фиксятся, пулл-реквесты принимаются — проблема «замкнутого» API не столь остра, но ведь так бывает не всегда, и в моей практике «бывает» очень редко.
Но помеха. Зачем эта помеха существует?
Вообще, нужно подойти к вопросу с другой стороны: нахрена закрывать API?
Когда мне сливали то-что-нельзя-называть в минуса, мне на мои предложения юзать exfat заявляли, что он чёт не оч
Слабаки https://geektimes.ru/post/257670/