Комментарии 112
интересно, почему не на https://github.com/JetBrains/compose-jb ?.. Получается в компании как минимум 2 собственных фреймворка для построения кроссплатформенного UI
Ну понравилось ребятам из JetBrains делать фреймворки. У них еще ведь есть биндинги Skia для Java. А вообще, для Fleet это объясняется так:
The UI framework is similar to Compose, but we started when Jetpack Compose wasn’t there :)
Видимо они много экспериментировали с графическими оболочками и возможно со временем какой то из фрейворков будет объявлен как deprecated.
Это движок для рендера иерархических графических компонентов, и при разработке достаточно сложного графического интерфейса своими силами у вас тоже получится такой же ЕЩЁ ОДИН браузер :). Дополню старинный тезис «любая достаточно сложная программа - это не дописанная лисп-машина» тезисом «любой достаточно сложный гуй - это не дописанный веб-браузер» :).
Так то да, но браузер имеет гору legacy и необходимость обратно-совместимо это всё поддерживать. Если писать "рендерилку иерархических графических компонентов" с нуля, то можно сделать "то что нужно", и не делать "то что не нужно". И быть в этом деле успешнее.
HTML (5) уже давно про приложения, а не про бумажную вёрстку, да.
Вы сильно демонизируете веб и браузеры, очень-очень-очень трудно будет написать движок лэяутов эффективнее того же вебкита (если у вас не просто пара кнопок в интерфейсе), а чтобы это ещё и кроссплатформенно было, и с богатствами типа видео или анимированных стилей, и с национальными шрифтами, и прочая и прочая. И ХТМЛ5 - это стек технологий, разрабатываемый СПЕЦИАЛЬНО для таких rich-приложений (на ХТМЛ4 он лишь "случайно похожий" некоторыми тегами, не более :))
очень-очень-очень трудно будет написать движок лэяутов эффективнее того же вебкита
Ну не знаю, по моему опыту приложения на QML в среднем заметно более отзывчивые, чем на Electron. При этом все перечисленные «богатства» и кроссплатформенность там есть.
Конечно, это субъективно, и для объективного сравнения нужны приложения с идентичным функционалом, разработанные командами равного уровня в равные сроки, но причины не любить электрон есть.
Сижу на ВЦ-коде, после всех нативных и джавовых IDE - глоток свежего воздуха и эталон отзывчивости. Да, это субъективно, и да, такого качества разработчики добились не с самой первой версии (ооочень сильно переработали редактор под капотом, теперь хоть гигабайтовые файлы открывай), да и сам электрон с хромом не стоят на месте :). В общем, вполне может оказаться, что детские болезни, отвернувшие вас от «настольного веба», уже устранены (не знаю) :).
Если не ошибаюсь, у GTK+ тоже есть подобный «браузер».
но всё-таки молотком забивать удобнее и быстрее.
А можно пример? Просто мне кажется, что браузер это уже не молоток, это давно мульти-тул. Скажем с появлением CSS3 многие вещи стали кратко удобнее. В HTML тоже много вкусных плюшек завезли. Да и inline SVG очень удобная штука. Для хитрых вещей есть canvas.
А, да, он ещё и дорогой. Особенно, если учитывать бесполезность значительной части возможностей. Это если про мультитулы. А браузер — тяжёлый, потому что за универсальность надо платить. При том, что половина, если не больше, просто не нужна для построения интерфейсов. Не говоря уже об обеспечении обратной совместимости по отображению документов, которая тут вообще ни при чём.
Я потому и говорю, пример бы. А то может получиться что мультитул, хоть и медленнее узкоспециализированных конкурентов, но всё таки удобнее (как ни странно). И не потому, что мультитул. А потому что над ним работает уже которое десятилетие куча народу, и в него вливают тонны денег. Бывает так. что бабло побеждает логику. И теория не подтверждается практикой.
Пример чего?
Пример того когда на web сделать UI неудобно, а не {other technology} удобно.
Системы, строящей интерфейс по документу с описанием?
Ну так в web такого полно. Ограничений нет. Одна из первым моих задача 12 лет назад была — написать генератор в меру сложных форм по JSON-у.
Пример того когда на web сделать UI неудобно, а не {other technology} удобно.Почти всегда: в никуда сжираются ресурсы системы и время пользователя, не говоря уже о низкой надёжности такого интерфейса, ломающегося из-за чего попало. Да хоть баннерорезка может сломать.
Ну так в web такого полно.Нет, это не по описанию, это средствами документа. Это похоже на интерфейс книги-игры. Да, играть можно. но настолько криво и неудобно, что только от плохой жизни таким пользоваться и будешь. Но нет, некоторые пользуются костылями и говорят, что ходить без костылей — это для гиков.
Вы на какой-то другой вопрос ответили. Я спросил про удобнее, а не про производительность. Про "средствами документа" ничего не понял. Приведите, пожалуйста, конкретный пример.
Да хоть баннерорезка может сломать.
А давно в GTK интерфейсах появились баннерорезки? Зачем вы приводите изначально не относящиеся к делу примеры?
Что касается «удобнее», то, видимо, стоит внимательнее изучить Qt c идущими в составе этого фрэймворка QScript и QML.
Баннерорезки в браузерах
Ага. В GTK их нет. Т.е. ваш довод можно трактовать так: "у них ломается то, чего у нас отродясь не было". Не понимаю зачем вы привели этот аргумент. Он точно не в пользу GTK. К тому же какие блин баннерорезки в Electron-е?
Что касается «удобнее», то, видимо, стоит внимательнее изучить Qt c идущими в составе этого фрэймворка QScript и QML.
Я думал вы пример приведёте. А вы меня посылаете изучать чужую платформу. Да ещё и внимательно. Это наверное с неделю. Спасибо что хоть не на три буквы (хотя это примерно тоже самое).
Давайте тогда завершим этот спор. Примеров у вас нет. Сообщения вы мои по диагонали читаете, посему отвечаете не на поставленные вопросы, а не те, которые сами хотите. Да ещё и нерелевантные аргументы приводите.
При всём при том, что мне просто интересен какой-нибудь кейс, когда на вебе что-то делать очень сложно, а на GTK очень удобно. Я ведь даже не спорю, что такие кейсы должны быть.
«у них ломается то, чего у нас отродясь не было»Потому и не ломается, что не было. За ненадобностью. Но Вы почему-то считаете, что это недостаток.
А про баннерорезки — это не про Electron, а про веб, про который Вы помянули.
Я думал вы пример приведёте.Таки пример чего именно Вам надо? Системы, которая генерирует интерфейс по описанию? Так ведь Qt+QML.
когда на вебе что-то делать очень сложно, а на GTK очень удобноУдобство «сделать» зависит от набора актуальных навыков разработчика. А вот удобство «пользоваться» — вот тут Electron проигрывает с разгромным счётом, поскольку сжирает ресурсы компьютера в никуда, при том, что то же самое можно было бы сделать в разы более лёгким и быстрым. Да, я понимаю, что можно взять i9 о 128 ядрах и с парой терабайт ОЗУ и там всё будет летать, только это не показатель умения программировать, это показатель толщины кошелька пользователя и развитости вычислительной техники, компенсирующей криворукость разработчиков, которые изучили JS и немного CSS и несут это немногое везде, где могут.
Одно дело — временный костыль вроде AppImage, который позволяет скачать и сразу запустить и попробовать, и совсем другое — использование на постоянной основе.
И при этом Pidgin и Leafpad будут использовать один экземпляр GTK2.0, а Claws Mail, XFCE4, Transmission и ещё куча всего пользуются одним экземпляром кода GTK3.0, хотя, конечно, это не очень хорошо: в идеале все они должны пользоваться одной версией и желательно — последней, но это уже мечты.
А за пределами Linux это тоже так работает?
А, да, во FreeBSD система зависимостей тоже работает.
это недостаток, а не то, на что надо ссылаться, оправдывая лень разработчиков
Я просто привык исходить из реальностей, а не фантазий\пожеланий. Нас, линуксоидов, два с половиной человека. Наши хотелки никому не интересны. А в других ОС, обычно, софт всё, что ему нужно, тащит сам с собой. Так выгоднее бизнесу. Да и в наш мир проникают эти appImage-ы, snap-ы и прочее. И мы можем сколько угодно ворчать о несправедливости и несовершенстве этого мира, от этого ничего не изменится.
и не бить по рукам тех
Для нас и так толком никто софт не пишет, а вы тех немногих, кто пишет, предлагаете бить по руками. Ох.
и хорошо работает.
Плохо, плохо работает. Я уже не раз отказывался от софта, который не удавалось установить из-за конфликта совместимостей. Полезного софта.
А с тем, чтобы что-то не ставилось из-за зависимостей, я не сталкивался уже лет 10, если не больше.
я не сталкивался уже лет 10, если не больше.
Ну вот кто просит засовывать интерпретатор Python в AppImage, если он уже есть в системе
На моей практике, чаще всего, как раз из-за того, что свою копию python-а в образ не засунули, приложение и не работает. Что-то там не ладится с совместимостями уже в экосистеме самого питона. Причём узнаешь об этом уже в логах при запуске. И чёрт его знает как это всё дело фиксить (я не питонист).
P.S. Я таки питонист и как раз притаскивание своей версии питона жутко бесит, потому что в системе есть свой. Внезапно. И если система актуальная, то проблем не возникает. Проблемы вылезают, когда надо что-то делать на системе, которую собирали из какой-нибудь Ubuntu LTS года через 2-3 после выхода, а потом оставили вариться в собственном соку лет на пять. Тогда конечно ничего не будет запускаться.
Я уж не говорю про то, что собрать DEB и RPM — это один раз файлы конфигурации написать, а потом только команду сборки запускать.
А вы можете назвать хоть один программный продукт, авторы которого не поленились этого сделать и предоставляют пакеты для всех актуальных версий всех популярных дистрибутивов?
А если популярными считать не только Ubuntu, Mint и Fedora?
Существующие пакетные менеджеры хорошо работают для свободного/открытого ПО, потому что мейнтейнеры дистрибутивов могут сами собирать его в соответствии со стандартами, принятыми в конкретном дистрибутиве.
Для проприетарного же ПО обеспечение лёгкой установки и безпроблемной работы на всём многообразии линуксов — непосильная задача. И именно эту проблему и решают AppImage, Flatpak и snap, каждый со своими компромисами.
Но даже DEB и RPM перекроют большую часть дистрибутивов.
А вот и нет, уже с deb вы легко можете столкнуться с несовместимостью разных версий зависимостей, а с RPM всё ещё гораздо сложнее — его используют совершенно независимые друг от друга дистрибутивы, в которых легко одна и та же зависимость может иметь разное имя. Для SUSE и Fedora вам понадобятся два разных RPM.
В snap и Flatpak есть механизмы дедупликации зависимостей, а AppImage на мой взгляд временное явление.
А если я захочу поставить клиент Discord-а, то в памяти будет висеть уже 4 браузера.
Знаете, я видел десктопный таск менеджер. Устроен он был так — фронт на электроне, как полагается. А еще там же был бэк — на PHP с апачем. И все это завернуто в десктопный пакет.
Если была б нода, то вышел бы очередной вскод. Вообще для подправить мне нравится Kate от кедов(да и вообще любой блокнот выпущенный для линукса, ведь линуксом пользуются программисты, и это все прекрасно знают).
Вскод на ссд открывается моментально, но на hdd electronjs даёт о себе знать
Не очень получается распарсить. Это выходит kotlin native + rust (тоже native), то есть без JVM в конечном итоге?
Одно дело когда что-то нативное вместо электрона, а другое если jvm, выходит шило на мыло, еще со времен eclipse не припомню ни одного приложения на яве, которое бы не подлагивало.
Так-то предыдущие IDE от JetBrains тоже работают через JVM, и достаточно быстро
Пробовал WebStorm с джетбрейновским jvm, на моем ноутбуке(ssd, i5, 12g ram) работать не очень комфортно, во время редактирования кода рандомно фризится на пару секунд и даже когда все работает нормально есть заметная на глаз задержка ввода. В vscode отзывчивость сравнима с нативными редакторами(например, sublime и cudatext), хотя и уступает обвешанному плагинами neovim.
Sublime, как по мне, на голову быстрее vscode.
По скорости загрузки быстрее, в остальном я бы не сказал, что сублим значительно быстрее.
На больших документах уже на глаз заметно быстрее открытие/поиск/навигация.
Проверял на js сборке в 100к строк и 4.5мб(ибо я не знаю где еще может встретиться такой большой исходник):
Настроенный сублим с расшинениями тормозил нищадно, сброс помог, грузится с прогрессбаром секунд 5, после чего работает приемлимо, при прокрутке есть незначительный лаг.
Cudatext наотрез отказался от подсветки и открыл моментально(на меньшем файле подсветил и тормозил)
Nvim(не голый) - открывает 3с, работает так же быстро как и с другими файлами, но перемещение к концу файла - 3с
Vscode - открывает 6с, правка и поиск работают отлично, при прокрутке начинает обрабатываться подсветка, небольшой лаг через некоторое время пропадает.
Подытожил я бы так, они все не идеально справляются с этой задачей, на практике мне не приходится работать с такими исходниками.
P.S. sublime единственный, кого пришлось сбросить, по хорошему надо проводить отдельный тест с чистыми и рабочими конфигурациями.
Vscode — открывает 6с, правка и поиск работают отлично, при прокрутке начинает обрабатываться подсветка, небольшой лаг через некоторое время пропадает.
Спасибо.
Похоже его сильно оптимизировали с тех пор как я его последний раз смотрел.
А еще уточните плз ОС? По отзывам, на макоси иногда могут быть фризы при работе с текстом.
Не понял, будет ли оно работать без Space-а и интернета?
Что касается количества разработчиков в посёлках, я не знаю, сколько их. Но вот работать с Geany можно и без сети, как и с Eclipse и много с чем ещё. Или с плохо работающим доступом в сеть. А если делать продукт, который обязательно хочет этот самый доступ в сеть, но при этом такой доступ не требуется для его основной функции, то это будет очень плохой продукт. Впрочем, уже написали, что Fleet работает и без сети. Просто у него есть функция удалённой разработки.
Я каждый день в поезде провожу около часа своего рабочего времени. Если не будет возможности кодить в поезде - придётся на час больше работать в офисе или дома
Иногда соединение с интернетом сильно тупит (много wi-fi вокруг). Иногда интернет дорогой (роуминг). Иногда нет возможности подключиться вообще (в здании без wi-fi где интернет не ловит, или ледяной дождь обесточил весь район на неделю).
А вообще, для простого редактора кода подключение к интернету обязано быть второстепенной функцией.
Будет. Backend поддержки сложных проектов может быть запущен локально.
P.S. JB Mono шикарен, огромный за него респект
>Сейчас это выглядит как VSC/Sublime со вшитым LSP
Это как вскод, но
Код закрыт
ЛСП нет
Поддерживает в разы меньше языков
Лично мне не понятна цель создания этого редактора. IDE? Уже есть, тем более от джетбреинс. Универсальный редактор кода? Вскод.
Уже есть, тем более от джетбреинс.
Проблема сейчас в том, что у JB под каждый язык используется своя IDE, а это не очень удобно. Хотелось бы видеть одну универсальную IDE, но с полноценным функционалом, а не VS Code.
Вроде бы C++ исключение, для него действительно нужен отдельный Clion, хоть я и не понимаю, почему.
А ещё C# — исключение, для него нужен отдельный Rider. А мне как раз C# и C++ нужны, иногда Python. В случае JetBrains это получается три разных IDE.
Для сравнения: Visual Studio (не Code) поддерживает всё в одной IDE и до кучи умеет в одновременную отладку C# и C++.
А ещё C# — исключение, для него нужен отдельный Rider.
А поддержка Unreal Engine (С++) есть только в Rider. Почему не в CLion? Очевидно они решили сделать из Rider специфическую IDE для геймдева, с нацеливанием на сегмент студий. Иначе его покупать не будут.
Имхо, JB пошли по самому ужасному пути, упаковывая каждый свой продукт в отдельное приложение и богомерзкий snap. Pycharm + CLion + Rider и вот у тебя уже захавано прилично места. Почему не сделали расширения плагинами, как в Eclipse?
Имхо, JB пошли по самому ужасному пути, упаковывая каждый свой продукт в отдельное приложение и богомерзкий snap.
Так ничто не мешает скачать напрямую или через тулбокс.
К слову, в snap оно занимает намного меньше места и устанавливается моментально, т.к. ничего не надо распаковывать:
Snap: Rider — 1043M одним файлом, CLion — 767M
Native: Rider — 2400M, 6500 файлов.
Ну а насчёт отдельной IDE под каждый язык: на то были причины. IDEA же гвоздями прибита к Java, и по-простому прикрутить к ней C# было почти нереально.
Idea ultimate же, как минимум для большинства.
Нужен для более тесной интеграции в экосистему JetBrains. Со всеми вытекающими отсюда последствиями.
Очень удобно для корпораций, удаленная разработка на площадях компании, опять же контроль, трекер рабочего времени не трудно присобачить.
И будет стоить в N раз дешевле полноценного продукта JetBrains? Слова Free в анонсе нет. А чем оно лучше бесплатного VSCode?
Нужно не нужно вопрос конечно интересый. Но то что они вместо электрона сделали надстройку на skia это круто. Flutter уже показал что это работает хорошо. Может выйти очень интересная платформа для разработки десктоп прилаг.
Flutter уже показал что это работает хорошо
Несогласен насчёт флюттера. Мобильные приложения на нём адски тормозят, хотя в том же Android Skia — часть системы и работает плавно. Но стоит запустить какое-нибудь флюттер приложение вроде Яндекс.Go или Vox… пиши пропало.
Возможно тормоза - это не вина Flutter, а тех, кто пишет на нём "Яндекс.Go или Vox"
З.Ы. Флаттер далеко не идеален и не самая производительная штука — но куда лучше электронов. Для кроссплатформы альтернатив вообще не вижу сейчас. Другое дело что в мобильной разработке многие сейчас упоролись в архитектуры ради архитектур, и это накладывать оверхед может.
А в яндексе оно встроено в натив и только часть UI через него, и там наверно много времени на прогрев тратится после запуска куска на флаттере.
Для кроссплатформа есть Qt. На мобилах так вообще только натив, потому что там ограниченный ресурс, прежде всего батареи. Но да, сложнее же, дольше, а качество... да кому оно нужно
Тогда откуда такой долгий и адский "прогрев" во всех смыслах?
З.Ы. вообще вот такое вот решение со встраиванием флаттера как я слышал в целом довольно проблемное, и для нормальной его работы в таком режиме хитрить надо.
Приложение медузы написано на флаттер (когда на хабре была статья), можете его попробовать, вроде было не плохо.
А, и на каком девайсе тестировали то?
Когда это Яндекс.Go стал flutter приложением?
У VSCode отвратительная поддержка шарпа, а в остальном она божественна. Подожду поддержки шарпов в этой IDE и попробую. Rider после vsCode выглядит как монстр.
Сравнить IDE с текстовым редактором - сильно
А что есть в IDE но нет в вс коде? Давайте списочком, так от трёх пунктов. А то не интересно.
Вы серьёзно? Берёте IDE, смотрите главное меню и сравниваете с VS Code. В случае C# наберётся минимум 10 пунктов:
Навигация.
Рефакторинг.
Генерация кода.
Полноценная поддержка системы сборки.
Режимы запуска с различной конфигурацией.
Полноценная отладка с просмотром значений переменных, потоков.
Тесты, анализ покрытий.
Статический анализ кода.
Профилировщик.
Просмотр IL кода.
GUI интерфейс для NuGet.
Работа с ресурсными файлами.
А так да, для солюшена, состоящего только из одного проекта и нескольких файлов, VS Code вполне хватает.
Пробежался по вашему списку для TS\JS в vsCode:
- yes
- yes
- no
- no
- yes
- yes
- yes
- yes
- no
- unrelated
- unrelated
- unrelated
Касательно 3, 4 и 9, не знаю как с этим в webStorm. Если сильно лучше чем "no", было бы интересно сравнить. Скажем в vsCode есть возможность запуска npm-script-ов, что едва ли можно назвать "полноценной поддержкой системы сборки". Но учитывая какой у нас зоопарк систем сборок и их настроек, не уверен что хоть кто-то брался за это дело на уровне GUI. Могу ошибаться.
С кодогенерацией тоже сложно. Кажется есть удачные решения для Vue и Angular, но в общем и целом у нас это очень нераспространённая практика, ввиду того той же самой вариативности. Чёрт его знает что и как генерировать, так чтобы в этом оставался какой-то смысл. А всякие сниплеты и макросы — есть.
Можно ли после этого считать что vsCode для TS\JS это IDE? Или всё ещё "текстовый редактор"?
не имеет значения где находится проект — локально, в контейнере или же на удаленном сервере.
Скажите, не совсем понимаю. Есть проект на c/c++, но собирается только на Linux. Я могу хостить исходники на локальной Linux машине, а разрабатывать проект на маке? То есть компиляция проекта также будет происходить на Linux, а не локальной IDE окружении/toolchain? Проблема: хочу разрабывать на маке (просто привычнее), но так как часть туллинга/зависимостей нет на маке, то CLion например практически не подсвечивает (autocompletion, definitions) проект.
Да, судя по приведённым схемам, это эквивалентно запуску IDE на удалённой машине, а локальная машина становится тонким клиентом.
Ждать уже не надо) Можно пробовать New Remote Development в CLion (https://www.jetbrains.com/remote-development/) уже начиная c 2021.3. JetBrains Gateway уже поддерживает CLion.
For remote development, the CLion instance runs locally, and your source files are also placed on the local client, with automatic synchronization to the remote host. On the remote host side, CLion performs compilation and build using host compilers and CMake/make, uses host GDB for debug, and runs the application on the remote target.
Синхронизация файлов с удалённым сервером, удалённая компиляция и отладка, всё по ssh.
Да, так делать можно, но это не решает проблему @house2008:
так как часть туллинга/зависимостей нет на маке, то CLion например практически не подсвечивает (autocompletion, definitions) проект.
Это вы читаете описание старого remote dev в CLion. А с 2021.3 есть новый, через JetBrains Gateway, смотрите по ссылке в моем сообщении
А, ну тогда просто ссылка не та была. Вот правильная:
https://www.jetbrains.com/remote-development/gateway/
Интересно. Сейчас попробую.
Я дала ссылку на корневую страницу про remote dev. Это новая технология. Старый remote dev тоже пока остается в CLion (через создание тулчейна, описание которого вы запостили). Сейчас новую технологию конкретно в CLion можно использовать только через Gateway. В Release Candidate уже работает. На днях будет релиз и мы напишем чуть подробнее тут на Хабре.
Upd: попробовал, действительно работоспособно.
Единственный нюанс: оно не использует установленную IDE, а выкачивает отдельный инстанс на удалённую систему.
С Fleet видимо, просто произойдёт унификация локального и удалённого доступа.
Вы уже сейчас можете делать плюс-минус тоже самое с помощью JetBrains Gateway https://www.jetbrains.com/help/idea/2021.3/remote-development-a.html#launch_gateway
Просто Fleet - IDE специально для этого созданная и улучшающая опыт от удалённой разработки, а Gateway сделан на существующих технологиях и использует толстый клиент конкретной IDE на сервере, например, CLion, и тонкий клиент Gateway (который только рисует интерфейс толстого) с вашей стороны.
All Products лицензия его покроет? Или отдельно надо будет брать?
JetBrains представила легковесную среду разработки Fleet