Полностью согласен, в примере с ES6 тоже не все обратимо. Мне больше нравится более узкий термин для таких инструментов.
Compiling is the general term for taking source code written in one language and transforming into another. Transpiling is a specific term for taking source code written in one language and transforming into another language that has a similar level of abstraction.
В любом случаи, есть все шансы получить обратно очень даже качественный код (конечно, не исходный), особенно, если большая часть этого кода была скомпилирована автоматически.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
var User = (function () { function User() { ... }; User.prototype.name = ...; return User; }());
Стрелочные функции, которые выглядят как то так
(function () { return ({...}); });
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Да, возможно, кому-то как и мне будет радостно узнать, что актуальные версии редактора есть под linux.
Пробовал запускать демки на Linux Mint, очень круто, просто дальше их сайта никогда не заглядывал.
Есть инструменты ES5 -> ES6, например lebab. Возможно есть подобия и для TS.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Верно, типизация в TypeScript опциональна и не причиняет больших не удобств, даже наоборот! )
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Расширяется все и атомы тоже, но расширение в области атомов чуть медленнее, чем в области протранства между атомами (зависимость от энергии) и поэтому кажется, что атомы отдаляются. Мне почему-то легче представлять все наоборот, что вселенная отсается прежней, а объекты в ней уменьшаются пропорционально имеющейся энергии и поэтому кажется, что все будто бы разлетается. Не знаю, эквивалентны эти взгляды или нет.
10 мин процессорного времени для экономии 1 гигабайта.
Потом каждый раз по 5 мин с кэшированием и надеждой переложить на пользователей и их браузеры.
Если не ошибаюсь, тут пропорционально увеличиваются риски, так как возрастает ценность битов…
Не тоже самое, конечно, что реплику отключить на несколько петабайт, но все равно))
Я бы назвал эти искусственные ограничители (цена, зрелищность, компактность) преимуществами, которых нужно добиться и философский как бы не станет. А результат у вас, действительно, получился зрелищным и увлекательным, очень круто.
Здесь уже отмечали проблему серверных решений и самого стандарта, поэтому не стал расписывать.
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
Я бы посоветовал попробовать на транслирующем сервере nginx-rtmp модуль, вся работа будет напоминать работу со статикой (ретрансляции, балансировки, cdn… )
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
В начале статьи вы написали три проблемы. В итоге не решили ни одну из них, почему-то выбрав архитектуру, в которой p2p используется в последнюю очередь.
Частичку перфекциониста во мне всегда тревожат эти func, nil, fmt ..., когда всякие interface, package, struct написаны нормально.
Особенно когда часто переключаешься с js и обратно.
У библиотеки goleveldb, которую вы подключаете есть mem storage, было бы тоже интересно посмотреть в сравнении с tarantool, которая позиционирует себя как in-memory db
Да, увидел в коде подключение реализации leveldb на go. Не специалист по go, возможно стоило использовать обертку на go для leveldb или вынести в отдельную программу и общаться с ней. Понятно, что это будет чуть медленней, но решило бы проблему атомарности.
Dokkur ..., cвоя PaaS,… из России… Простите, но пост немного высокомерный по отношению к сообществу и разработчикам Dokku, несмотря на вашу работу по написанию интерфейса с биллингом и развертыванием. В любом случае, искренне рад вашему успеху. Всегда существовало недопонимание, почему в России везде всякие VDSmanager и доступ по FTP, когда даже обычные разработчики пишут на хабре посты как поднимать свою инфраструктуру с помощью Docker Swarm и тд.
Кстати, про scope, введенные для решения проблемы. Попробовал создать организацию такую же как на гитхабе, откуда такая цена — 14 баксов в месяц? За то что эта якобы общественная организация хранит в своей базе одну страницу с зеркалом на гитхаб? Зачем мне тогда именоваться у них вот так @organization/module, если я могу просто указать organization/module и у меня все равно из гитхаба все подгрузит
В любом случаи, есть все шансы получить обратно очень даже качественный код (конечно, не исходный), особенно, если большая часть этого кода была скомпилирована автоматически.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
Стрелочные функции, которые выглядят как то так
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Пробовал запускать демки на Linux Mint, очень круто, просто дальше их сайта никогда не заглядывал.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Интересно, насколько вредно вдыхать такой пластик
Потом каждый раз по 5 мин с кэшированием и надеждой переложить на пользователей и их браузеры.
Если не ошибаюсь, тут пропорционально увеличиваются риски, так как возрастает ценность битов…
Не тоже самое, конечно, что реплику отключить на несколько петабайт, но все равно))
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Ну технологии и цели, конечно, тут разные
интересен вклад стабилизаторов и сколько топлива требуется чтобы он стоял как вкопанный, на примере такого опытного человека не понять
Особенно когда часто переключаешься с js и обратно.
У библиотеки goleveldb, которую вы подключаете есть mem storage, было бы тоже интересно посмотреть в сравнении с tarantool, которая позиционирует себя как in-memory db