Здравствуйте, Shmj, Вы писали:

S>Еще варианты есть?

чтобы мало-мальски прилично было на линуксе, варианта ровно два: GTK и QT.
если надо ещё и под винду, то только QT.

P.S.
однако, C# + winforms, в общем-то, и на линуксе прилично работает через mono.

Здравствуйте, AlexGin, Вы писали:

AG>А какая религия мешает просто взять Qt и работать себе в удовольствие?

Мысль о C++ у многих вызывает боль, у меня в том числе. Хотя небольшой опыт работы с ним есть, но углубляться желания не возникает.

C# и Java — наиболее прекрасные языки, имхо. Все что сверх того — от лукавого.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет?

Потому, что пока НЕ СУЩЕСТВУЕТ адекватного кросс-платформ инструмента.

S> Прога типа простого графического редактора узкой направленности

.NET + WinForms.
Миллионы адекватных юзеров только спасибо скажут.

Здравствуйте, Shmj, Вы писали:

S>На чем бы вы писали десктопную прогу для Linux?

На Windows.

S>Если есть возможность кросс-платформы, скажем так, то почему нет?

Если бы была такая беспроблемная возможность, то и вопроса бы не было. А так, начальная ценность фичи отрицательная и её надо чем-то отправдать, чтобы хотя бы выйти в ноль.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Lazarus. Можно даже с интерфейсом Qt, чтоб не сильно различался интерфейс с виндой. Компонентов под него прорва. Есть, конечно, и ложка дегтя, куда ж без нее. Но оную можно везде найти.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, MaxRos, Вы писали:

MR>> S>Там нельзя писать десктопные проги с GUI — только сайты и консольные проги.

MR>> можно

R>Только если на look and feel плевать.

look and feel в линуксе? а вы шутник

Здравствуйте, Shmj, Вы писали:

S>Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

В настоящее время, для подавляющего большинства программ размер не имеет решающего значения. Скорость разработки сильно важнее.

Здравствуйте, Kolesiki, Вы писали:

K>Свобода, которую предоставляет Линукс
Это не свобода, это бардак.

Здравствуйте, AlexGin, Вы писали:

S>>>Если есть возможность кросс-платформы, скажем так, то почему нет?

A>>Если бы была такая беспроблемная возможность, то и вопроса бы не было. А так, начальная ценность фичи отрицательная и её надо чем-то отправдать, чтобы хотя бы выйти в ноль.
AG>
AG>Не понятно, в чём же вопрос?
AG>ИМХО кросс-платформенная разработка всегда важна и ценна.

Неочевидно. Кросс-платформенность важна и ценна, когда реально нужна.

1. Если пишешь для себя, а ты на Windows, то кросс-платформенность не нужна.
2. Если пишешь для конкретно кого-то, а он/она на Windows, то кросс-платформенность не нужна.
3. Если пишешь для некоей целевой аудитории, и есть понимание, что они все на Windows, то кросс-платформенность не нужна.
4. Если пишешь неизвестно для кого, то зачем?

AG>Отчего же "ценность фичи отрицательная"?
AG>Если можно — поясните, плиз.

"Начальная ценность"
Это про любую фичу вообще. Вот пришла тебе в голову идея новой классной фичи — отлично, но теперь её надо будет как минимум
а) продумать/задизайнить,
б) реализовать,
в) протестировать,
г) до бесконечности поддерживать, чтоб не поломалась.

Если фича действительно нужная, решает реальную проблему, то все эти усилия окупаются, ценность фичи выходит в плюс. А если фича чисто для галочки и реальной пользы никакой, то ты просто впустую тратишь усилия.

Т.е. вопрос надо ставить не как "если есть возможность, то почему нет?", а как "кому-то это вообще надо?"

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.

Тебе ж графика нужна? Если "да" то где графика и где Java?

S>2. QT.

Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers.

Ну и коментарии

S>3. Electron?

Графический редактор предполагает т.н. immediate mode graphic. Т.е. что-то типа этого

function onPaint(graphics) {
  graphics.moveTo(...)
          .lineTo{...};
}

в Electron такого нет.

S>Еще варианты есть?

Всегда.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Ох, с кроссплаформенностью столько пережеванно. Но в итоге так или иначе приходишь к тому,что она нафиг не нужна.
Под кроссплаформенностью обычно подразумевают Windows + Mac + Linux.
Итого за несколько очень больших проектов такие выводы:

1. Windows — это то, на чём собственно зарабатываешь. То, что приносит деньги.
   
2. Mac — всегда донатная, нужная заказчикам чисто для галочки. Десктопный софт если не что-то стандартное — то делается с большой болью и через задницу. Кроссплатформенного GUI для него не существует — всё что есть так или иначе не вписывается в концепцию платформы, потому по-любому GUI придётся лепить нативный. Что в итоге сьедает огромный бюджет, который никогда не будет восполнен за счёт пользователей. Отбиваться по деньгам будут только простые приложения.
   
3. Linux — его проблемы с графической частою никогда не будут решены. Продавать софт некому. ИМХО, GUI там вообще не нужен. Во всех проектах когда заказчик настаивал — во всех софт никогда не был закончен, так как не находилось источников финансирования.

В остатке: пишешь под Windows на чём удобнее. Если Mac действительно окажется нужным — делаешь под него версию. Linux — всё, что с GUI не имеет смысла.

Здравствуйте, Shmj, Вы писали:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

4. WxWidgets
5. Lazarus + FreePascal

Не совсем уверен, но емнип Mono с GTk# оберткой может и под винду.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Delphi

Здравствуйте, Shmj, Вы писали:

S>Еще варианты есть?

Python + Qt

Здравствуйте, Shmj, Вы писали:

S>3. Electron?
S>Еще варианты есть?
По факту, Электрон лучше всего подходит для быстрой разработки.

Здравствуйте, Shmj, Вы писали:

S>Как вообще называется спец., который компетентен выбрать технологию? Это ведь не хухры-мухры — если ошибешься и оно будет тормозить — то месяцы разработки в труху.

Опытный спец?

Здравствуйте, AlexGin, Вы писали:

AG>ИМХО кросс-платформенная разработка всегда важна и ценна.
На самом деле нет.
На каждой ОС юзеры хотят чтоб софт выглядел и вёл себя по guidelines для этой ОС. Если только этот софт уже настолько популярен что имеет свои общепринятые стандарты.

Здравствуйте, AlexGin, Вы писали:

AG>Кому надо?
AG>Сегодня — почти никому, завтра — практически всем...
И когда же настанет это самое завтра? Уж много лет и всё никак.

Здравствуйте, Ikemefula, Вы писали:

I>то можно и на электроне
Канделябром за такое.

Здравствуйте, Ikemefula, Вы писали:

I>>>то можно и на электроне
CC>>Канделябром за такое.
I>Работает не хуже рисовалок на дотнети или джаве.

Не, нафиг. Уж лучше дотнет чем это говно. Жава тоже идёт в лес в том виде в котором она предполагается запускаться.

Здравствуйте, Ikemefula, Вы писали:

I>Единственное отличие это onPaint у дотнета. В жээсе такого нет, потому драг-дроп всегда будет рывками. Сама отрисовка ничем не отличается.
Пофигу, всё равно закопать.
Electron это abomination которому нельзя дать вырасти.

Здравствуйте, AlexGin, Вы писали:

A>>Неочевидно. Кросс-платформенность важна и ценна, когда реально нужна.

A>>1. Если пишешь для себя, а ты на Windows, то кросс-платформенность не нужна.
AG>Если завтра я на Linux — то тогда возможно два пути:
AG>a) — всё на кросс-платформенной базе (тот же Qt) — можно сделать версию под Linux с относительно небольшими трудозатратами;

А зачем? Твои юзеры сидят на этом линуксе?

A>>Это про любую фичу вообще. Вот пришла тебе в голову идея новой классной фичи — отлично, но теперь её надо будет как минимум
A>>а) продумать/задизайнить,
A>>б) реализовать,
A>>в) протестировать,
A>>г) до бесконечности поддерживать, чтоб не поломалась.

AG>Вот в том и ценность кросс-платформенного фреймворка, что всё это (ну почти всё) будет прямо из коробки

Точнее — ничего. Кросс-платформенный фремворк избавит тебя от написания процентов 80% платформенно-зависимого кода.
Это окупится только в том случае, если юзеры требуют разных платформ. В противном случае это будет медленнее — нативная разработка под конкретную платформу будет быстрее.

AG>Конечно же, я понимаю что (например) вызова WinApi напрямую не пройдут, придётся найти их POSIX аналоги.
AG>Файловая система и пути к файлам — также возможно придётся подправить напильником.
AG>Но это не так трудозатратно, как переделывать все с самого начала.

Это не так и легко, как кажется.

AG>Кому надо?
AG>Сегодня — почти никому, завтра — практически всем...

Кроссплатформенность это никакая не фича. Как только появится веб-решение, про твою кроссплатформенную рисовалку дружно забудут.

Здравствуйте, Ikemefula, Вы писали:

I>Итого — около 0%
Как удачно играешь со статистикой! Ну прямо как теперь играют со статистикой по ковиду

Теперь представим компьютерную структуру одного из наших Заказчиков:
Если у них 93% на Linux — значит, для моего круга пользователей это 93% (ну и Windows около 6...7%).

I>Инженерия это всегда экономически выгодные решения, а не абы какие.

Ну на, ну да — расскажи об этом конструкторам любого танка или БТРа например.
Да и в софтверной индустрии — не все сидят на "складах", "магазинах" и прочих "бухгалтериях".

I>А вот надо бы. иОс очень особенная.
Один из под-видов UNIX.
Я и так занимаюсь на Linux (также один из под-видов UNIX).

I>иОс не делаете, Мак тоже. А какие у вас платформы?
Linux — с его POSIX.
Windows с его WinAPI.

I>А это зависит от платформ. Чем сильнее они отличаются, тем хуже покрытие у фремворка и тем чаще тебе сидеть в нативе.

Спасибо, уважаемый КО.
Вот поэтому мне и приходится нередко заниматься и на POSIX, и на WinAPI. Но это даже вносит разнообразие в творческий процесс.

I>Выше описана проблема, когда фремворк не покрывает часть функциональности, что абсолютно нормально, а имеющиеся реализации во всех платформах имеют разные возможности и АПИ, что так же абсолютно нормально.

Еще раз повторюсь: при правильно проработанной архитектуре описанное — проблемой не окажется (и к большим трудозатратам не приведёт).

I>А ничего ломать и не пришлось

Уважаемый земляк Ikemefula, но ты вроде писал так:

Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности. А в теории надо бы добавить недостающую платформу. Снова гы-гы.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Если использовать C++, то для GUI есть не только QT. Список кросс-платформенных GUI-библиотек для C++.

Для других языков можно посмотреть https://www.slant.co/topics/983/~best-cross-platform-gui-toolkits и https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries

M>>не являются веб-технологиями, и народ уже достаточно массово избавляется от react native.
МР>Интересно. А почему, не говорят?

Например, AirBnB: https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a

Здравствуйте, LuciferSaratov, Вы писали:

LS> если надо ещё и под винду, то только QT.

Или wxWidgets, но только если ради высоких идеалов.

Здравствуйте, CreatorCray, Вы писали:

vsb>>Экзешник хочешь? Современная джава умеет.
CC>А он будет одним процессом или самораспакуется и запустит грёбаный зоопарк?

Самый настоящий экзешник, даже код прекомпилируется. Хелло ворлд весит около 6 МБ. Никакого обмана. Называется GraalVM если что. Судя по гуглу со Swing пока проблемы, а JavaFX кто-то запускал. Хотя, думаю, при большом желании всё можно сделать, просто оно никому особо не надо.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?
U++

Здравствуйте, LuciferSaratov, Вы писали:

S>>Еще варианты есть?

LS>чтобы мало-мальски прилично было на линуксе, варианта ровно два: GTK и QT.
LS>если надо ещё и под винду, то только QT.

wxWidgets

Здравствуйте, Shmj, Вы писали:
...
А какая религия мешает просто взять Qt и работать себе в удовольствие?

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Java — swing, openFX

.Net — GtkSharp, Eto.Forms, Winforms, Avalonia UI (Skia)

nim (nim-x)

dlang — dlang UI

c — gtk(glade)

html5+js => canvs — тоже можно рисовать.

Здравствуйте, c-smile, Вы писали:

c> S>1. Java.

c> Тебе ж графика нужна? Если "да" то где графика и где Java?

JavaFX, например.

Здравствуйте, AlexGin, Вы писали:

AG>Сегодня — почти никому, завтра — практически всем...

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

Здравствуйте, Shmj, Вы писали:

AG>>А какая религия мешает просто взять Qt и работать себе в удовольствие?

S>Мысль о C++ у многих вызывает боль, у меня в том числе. Хотя небольшой опыт работы с ним есть, но углубляться желания не возникает.

S>C# и Java — наиболее прекрасные языки, имхо. Все что сверх того — от лукавого.

Когда я проследний раз использовал Qt 4, С++ там был крайне примитивный, процентов 30 от "настоящего" хардкора. Исключений нет, кодогенерация вместо шаблонной магии. В общем если тебя смущает только это — попробуй. То подмножество С++ как раз не сильно отличается от Java. Разве что сборщика мусора нет, но и на ссылках можно писать код.

Эта дискуссия, её тема,
является отличной иллюстрацией высказывания А.А. Фурсенко (бывший министр образования):

"Темпы изменений настолько возросли, что мы не то что не успеваем внедрять и использовать инновации, мы не успеваем их осознать"

Здравствуйте, Ikemefula, Вы писали:

AG>>Если завтра я на Linux — то тогда возможно два пути:
AG>>a) — всё на кросс-платформенной базе (тот же Qt) — можно сделать версию под Linux с относительно небольшими трудозатратами;

I>А зачем? Твои юзеры сидят на этом линуксе?
+100500
Да, бывает и такое — что люди ставят условие — работа на OS Linux.
Отмечу, что я занимаюсь в основном техническими и расчётными приложениями на C++

AG>>Вот в том и ценность кросс-платформенного фреймворка, что всё это (ну почти всё) будет прямо из коробки

I>Точнее — ничего. Кросс-платформенный фремворк избавит тебя от написания процентов 80% платформенно-зависимого кода.
I>Это окупится только в том случае, если юзеры требуют разных платформ. В противном случае это будет медленнее — нативная разработка под конкретную платформу будет быстрее.
Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.
Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

AG>>Конечно же, я понимаю что (например) вызова WinApi напрямую не пройдут, придётся найти их POSIX аналоги.
AG>>Файловая система и пути к файлам — также возможно придётся подправить напильником.
AG>>Но это не так трудозатратно, как переделывать все с самого начала.

I>Это не так и легко, как кажется.
Разработка на нескольких приличных проектах с подобными явлениями на практике — показала, что не так страшен черт, как его малюют.

AG>>Кому надо?
AG>>Сегодня — почти никому, завтра — практически всем...

I>Кроссплатформенность это никакая не фича. Как только появится веб-решение, про твою кроссплатформенную рисовалку дружно забудут.

В том стеке, на котором работаю я, веб-решения совсем не просматриваются как даже "хоть_какие" решения (sorry за каламбур).

Здравствуйте, AlexGin, Вы писали:

I>>Кому именно ценны и важны? Для конторы выгоднее всего поддерживать одну версию приложения. Начинать нужно с самой массовой. Если веб в планах, то лучше начинать именно с него, т.к. на данный момент это самая массовая платформа.

AG>Ну а если веба в планах нет? Тем более, что ниша веба постепенно перекрывается специализированными mobile решениями...

А я вижу, что мобайл замещается вебом:
— чистые веб-технологии, а именно — сайт, который адаптирован под мобайл
— PWA
— react-native, ionic и тд
— гибридные приложения, где БЛ и контент работают внури web-view

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

I>- чистые веб-технологии, а именно — сайт, который адаптирован под мобайл
I>- PWA

После превоначального хайпа PWA откусили нишу в размере 0.0001% рынка и выползать из нее не планируют. Потому что слишком много услилий даже для простейших вещей.

I>- react-native, ionic и тд

не являются веб-технологиями, и народ уже достаточно массово избавляется от react native.

I>- гибридные приложения, где БЛ и контент работают внури web-view

Таки были и есть, на победу веб-технологий это не тянет

I>Нативные нужны исключительно там, где нужен доступ к железу или максимальная производительность.

Ну то есть везде, где надо показать больше одной простой страницы с текстом и картинками (с чем веб тоже справляется достаточно плохо).

Здравствуйте, AlexGin, Вы писали:

I>>Какая доля луноходов в общей массе?
AG>
AG>Большая, если твой дом на Луне...

Итого — около 0%

I>>Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.
AG>
AG>...я никогда и не искал вакансию экономиста...

Инженерия это всегда экономически выгодные решения, а не абы какие.

I>>Всё остальное — по числу платформ и это в лучшем случае, т.к. могут быть нюансы, по нескольку версий в зависимости от возможностей какого нибудь иос.
AG>

Про окошки я скипнул, это даже не смешно.

AG>c) Для всяких там iOS не в курсе, ими не занимался.

А вот надо бы. иОс очень особенная.

I>> Именно это тебя ждет и в кроссплатформенной версии.
I>>Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
AG>...уже упоминал, что на Маке ничего не делаем...

иОс не делаете, Мак тоже. А какие у вас платформы? Если они похожи друг на друга, так это неинтересно.

I>>Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
AG>Про идеальный — никто и не говорит. Просто — достаточно хороший (в меру качественный).

А это зависит от платформ. Чем сильнее они отличаются, тем хуже покрытие у фремворка и тем чаще тебе сидеть в нативе.

I>>Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.
AG>
AG>Выше описана проблема архитектуры — что надо было выносить на уровень business logic, а что оставить в "реализационно-техническом слое".

Выше описана проблема, когда фремворк не покрывает часть функциональности, что абсолютно нормально, а имеющиеся реализации во всех платформах имеют разные возможности и АПИ, что так же абсолютно нормально.

AG>А в практике — хорошо продумать архитектуру проекта, чтобы потом не ломать...

А ничего ломать и не пришлось — достроили недостающее и всё. В одной платформе достраивали одно, в другой — другое. Если разница в возможностях слишком большая, типа "десктоп-мобайл" или "винда-иос", то других вариантов не бывает.

Здравствуйте, AlexGin, Вы писали:

I>>Итого — около 0%
AG>Как удачно играешь со статистикой! Ну прямо как теперь играют со статистикой по ковиду

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

AG>Теперь представим компьютерную структуру одного из наших Заказчиков:
AG>Если у них 93% на Linux — значит, для моего круга пользователей это 93% (ну и Windows около 6...7%).

Ключевое слово — "Если". Этого мягко говоря недостаточно, т.к. говорит о том, что ты не знаешь.

I>>Инженерия это всегда экономически выгодные решения, а не абы какие.
AG>
AG>Ну на, ну да — расскажи об этом конструкторам любого танка или БТРа например.

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

AG>Да и в софтверной индустрии — не все сидят на "складах", "магазинах" и прочих "бухгалтериях".

ОМГ! На примере — на "складе" инженеры должны думать, а если нет, то могут и всерьез позволить себе ахинею гнать?
Ну или там могут заняться никому не нужной работой, раздувать бюджеты во сколько угодно раз, ну или даже ничего не делать.
Какая разница, экономической целесообразности нет ведь

На самом деле эта целесообразность есть эффективность. Если ты сам пилишь неэффективные решения с тобой никто церемониться не станет. Странно что ты считаешь, будто инженер может себе позволить быть неэффективным или пилить неэффективные решения

I>>А вот надо бы. иОс очень особенная.
AG>Один из под-видов UNIX.
AG>Я и так занимаюсь на Linux (также один из под-видов UNIX).

Это общие слова. В иос даже ин-апп браузер требует приседаний, т.к. он очень особый — то координаты не те, то эвенты не такие, не так приходят, то скрипт не так работает, то цсс хилый. Только пофиксили — новая версия иос и все по новому.
Эти деятели умудрились сломать даже string.reverse

I>>иОс не делаете, Мак тоже. А какие у вас платформы?
AG>Linux — с его POSIX.
AG>Windows с его WinAPI.

ОМГ! Иос отличается и от того, и от другого и функционально, и качественно. Более того — в разных версиях все по разному.

AG>Спасибо, уважаемый КО.
AG>Вот поэтому мне и приходится нередко заниматься и на POSIX, и на WinAPI. Но это даже вносит разнообразие в творческий процесс.

Ты недавно писал про нативную часть
"Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)"
И оказывается, что в кроссплатформенном приложении если приходится писать нативное, то именно такое вот.

I>>Выше описана проблема, когда фремворк не покрывает часть функциональности, что абсолютно нормально, а имеющиеся реализации во всех платформах имеют разные возможности и АПИ, что так же абсолютно нормально.
AG>
AG>Еще раз повторюсь: при правильно проработанной архитектуре описанное — проблемой не окажется (и к большим трудозатратам не приведёт).

Ты из краткого эмоционального описания понаделал глубокоидущих выводов. Как это ты делаешь технические суждения из отсутствие подробностей решительно непонятно

I>>А ничего ломать и не пришлось
AG>
AG>Уважаемый земляк Ikemefula, но ты вроде писал так:
AG>

AG>Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности. А в теории надо бы добавить недостающую платформу. Снова гы-гы.

А где ты здесь видишь ломание? Это фактически расширение. В 4 раза больше работы — потому как 4 платформы. Ненужная — т.к. оптимистичный план состоял подмене компонента для иос.
Максимум, что можно было сэкономить — зная наперёд такую особенность, пропустить оптимистичный план начать сразу пессимистичный — 4 платформы. Вот и все.

Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

1. Java.
2. QT.
3. Electron?

Еще варианты есть?

Писал бы на C используя Gtk.

Здравствуйте, Shmj, Вы писали:

S>2. QT.
Есди это прямо граф редактор и ты не собираешься выезжать на пром. уровень с привлечением наймитов, то я бы взял QT(точнее QML) + OGL/Vulkan.
S>3. Electron?
Если надо будет потом набирать макак и это был бы не графический редактор, то выбрал бы его, хоть система такая себе и жёрт много памяти.
Посмотри в сторону sciter ещё.

Здравствуйте, Shmj, Вы писали:
...
Я все приложения для Linux делаю на C++ (Qt 5).
Но у меня есть друзья, которые пишут под OS Linux на C# (.NET Core).

S>Еще варианты есть?
.NET Core. от MS

P.S. Эта тема (.NET Core & Linux) недовно подымалась:
http://rsdn.org/forum/unix/7457418

Автор: okon
Дата: 29.05.19

Здравствуйте, AlexGin, Вы писали:

S>>Еще варианты есть?
AG>.NET Core. от MS

Там же только Web-приложения для Linux. Из GUI ничего нет.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:

AG>>А какая религия мешает просто взять Qt и работать себе в удовольствие?

S>Мысль о C++ у многих вызывает боль, у меня в том числе. Хотя небольшой опыт работы с ним есть, но углубляться желания не возникает.

S>C# и Java — наиболее прекрасные языки, имхо. Все что сверх того — от лукавого..
Тогда смело бери .NET Core и C#.

Здравствуйте, Kernan, Вы писали:

K>Тогда смело бери .NET Core и C#.

Там нельзя писать десктопные проги с GUI под Linux — только сайты и консольные проги.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Kernan, Вы писали:

K>>Тогда смело бери .NET Core и C#.

S>Там нельзя писать десктопные проги с GUI — только сайты и консольные проги.

можно

Здравствуйте, MaxRos, Вы писали:

MR> S>Там нельзя писать десктопные проги с GUI — только сайты и консольные проги.

MR> можно

Только если на look and feel плевать.

Здравствуйте, rudzuk, Вы писали:

R>Только если на look and feel плевать.

Да сейчас всем на него плевать.
Меня коробит, но большинству пофигу.

C>По факту, Электрон лучше всего подходит для быстрой разработки.

Зато для качественной разработки подходит едва ли средне.

Здравствуйте, LuciferSaratov, Вы писали:

LS>Зато для качественной разработки подходит едва ли средне.

Как вообще называется спец., который компетентен выбрать технологию? Это ведь не хухры-мухры — если ошибешься и оно будет тормозить — то месяцы разработки в труху.

Здравствуйте, MaxRos, Вы писали:

MR> R>Только если на look and feel плевать.

MR> look and feel в линуксе? а вы шутник

https://developer.gnome.org/hig/stable/

Здравствуйте, rudzuk, Вы писали:

https://developer.gnome.org/hig/stable/

https://hig.kde.org/

Здравствуйте, Shmj, Вы писали:
Ну есть же Xamarin.Forms.Platform.GTK/
https://github.com/xamarin/Xamarin.Forms/tree/master/Xamarin.Forms.Platform.GTK
https://github.com/jsuarezruiz/forms-gtk-progress

Здравствуйте, Shmj, Вы писали

S>Как вообще называется спец., который компетентен выбрать технологию? Это ведь не хухры-мухры — если ошибешься и оно будет тормозить — то месяцы разработки в труху.

vp of software architecture или chief decision maker как минимум

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет?
S>2. QT.

LuciferSaratov:

LS>чтобы мало-мальски прилично было на линуксе, варианта ровно два: GTK и QT.
LS>если надо ещё и под винду, то только QT.
GTK под винду тоже есть.

Здравствуйте, rudzuk, Вы писали:

R>Здравствуйте, MaxRos, Вы писали:

MR>> R>Только если на look and feel плевать.

MR>> look and feel в линуксе? а вы шутник

R>https://developer.gnome.org/hig/stable/

Спасиб, поржал! Линукс с толпами задротов прям всё бросит и побежит читать документ, название которого отражается в их мозг как "Вот так мы тебя ограничим, чтобы ты не делал лишнего". И что самое ржачное, это гайд ОДНОЙ ИЗ ДЕСЯТКОВ ГУЙ библиотек. В самой ГТк никто тебя слушать не будет, а представляешь, что в других творится??

Свобода, которую предоставляет Линукс, настолько развращает мозг школотронов, что ты вряд ли заставишь их делать всё единообразно. Наоборот — каждый недовольный прыщеглот считает своим долгом что-то форкнуть и накоммитить своё видение мира. Убирать только за этими засранцами некому.

Здравствуйте, Bill Baklushi, Вы писали:

BB>GTK под винду тоже есть.

да, только выглядит и работает так себе.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

Да, CCore.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Kolesiki, Вы писали:

K> Спасиб, поржал! Линукс с толпами задротов прям всё бросит и побежит читать документ, название которого отражается в их мозг как "Вот так мы тебя ограничим, чтобы ты не делал лишнего". И что самое ржачное, это гайд ОДНОЙ ИЗ ДЕСЯТКОВ ГУЙ библиотек. В самой ГТк никто тебя слушать не будет, а представляешь, что в других творится??

Фантазии виндовых дотнетчиков это интресно, но реальность немного другая.

Здравствуйте, Буравчик, Вы писали:

Б>Опытный спец?

У каждого спеца опыт в 1-2 технологиях. Обычно в одной. И он всегда будет склонять на свою технологию, в итоге может просто из-за неверного выбора технологии/спеца получиться У.Г., которое сильно тормозит и пользоваться которым не приятно.

Должен быть мета-специалист.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Буравчик, Вы писали:

S> в итоге может просто из-за неверного выбора технологии/спеца получиться У.Г., которое сильно тормозит и пользоваться которым не приятно.

У меня есть отличный пример того, как тормозное говнище может получиться независимо от выбранной технологии при почти одинаковых вводных. Под винду есть магазины-запускаторы игр от компаний Activision Blizzard и Electronic Arts — battle.net и origin. Обе они написаны с использованием Qt. Первый прекрасно работает и вообще не тормозит, второй — почти неюзабилное говно, проще сразу на сайт идти.

Здравствуйте, MaxRos, Вы писали:

MR>У меня есть отличный пример того, как тормозное говнище может получиться независимо от выбранной технологии при почти одинаковых вводных. Под винду есть магазины-запускаторы игр от компаний Activision Blizzard и Electronic Arts — battle.net и origin. Обе они написаны с использованием Qt. Первый прекрасно работает и вообще не тормозит, второй — почти неюзабилное говно, проще сразу на сайт идти.

Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, MaxRos, Вы писали:

S>Правильный выбор технологии — условие необходимое, но не достаточное. Вот смотрите — собрал я проект AvaloniaApplication пустой без кода — уже весит 66 Мб. Как-то многовато, имхо. Если при прочих равных прога конкурента будет весить 2 Мб. и запускаться быстрее — то будут любить ее.

Это всё демагогия, конечно, но я могу на это ответить так. Пока ваш конкурент будет упариватсья паковкой проекта в 2 мега, вы сможете выкатить продукт и начать продавать. А потом уже подумать об уменьшении размера, если понадобится (вряд ли).

Здравствуйте, Shmj, Вы писали:

S>Должен быть мета-специалист.

А дальше должен быть мета-мета-мета и т.д.? Не, в реальности так не работает. Во-первых, чем опытнее специалист, тем он дороже и его сложнее найти. Во-вторых, даже супер-специалист не может знать все.

Более реальный вариант — советоваться с несколькими людьми — с "глубокими" специалистами, знающими 1-2 технологию, и с менее "глубокими", но "широкими" мета-специалистами, которые знают 5-6 технологий, но менее глубоко. Но даже группа не может знать все.

В конечном итоге все равно кто-то должен принять окончательное решение в условиях неопределенности, взять на себя ответственность за это решение. Такой мета-мета-мета-специалист — менеджер (тимлид, архитектор, PM, CTO, CEO)

Здравствуйте, Shmj, Вы писали:

S>У каждого спеца опыт в 1-2 технологиях. Обычно в одной. И он всегда будет склонять на свою технологию, в итоге может просто из-за неверного выбора технологии/спеца получиться У.Г., которое сильно тормозит и пользоваться которым не приятно.

S>Должен быть мета-специалист.


На сегодняшний день, грамотно используя любую технологию программирования — можно сделать приложение-конфетку.
И при этом совсем не обязательно быть супер-специалистом.
Просто весьма важно придерживаться best-practices для выбранного стека. Ну и общих рекомендаций по разработке архитектуры.
На сегодня выбор технологии — это скорее дело вкуса, нежели принцыпа.
Конечно же, всегда важно понимать — где может оказаться "бутылочное_горлышко" проектируемой программной системы...

Здравствуйте, alexzzzz, Вы писали:

S>>На чем бы вы писали десктопную прогу для Linux?

A>На Windows.
+100500
Да, это один из вариантов кроссплатформенной разработки

S>>Если есть возможность кросс-платформы, скажем так, то почему нет?

A>Если бы была такая беспроблемная возможность, то и вопроса бы не было. А так, начальная ценность фичи отрицательная и её надо чем-то отправдать, чтобы хотя бы выйти в ноль.

Не понятно, в чём же вопрос?
ИМХО кросс-платформенная разработка всегда важна и ценна.
Отчего же "ценность фичи отрицательная"?
Если можно — поясните, плиз.

Здравствуйте, Shmj, Вы писали:

Чисто теоретически Qt 4.8.7.

Здравствуйте, velkin, Вы писали:

V>Чисто теоретически Qt 4.8.7.

Почему же такой древний?
Сейчас Qt 5.14.2 уже идёт.

Здравствуйте, AlexGin, Вы писали:

V>>Чисто теоретически Qt 4.8.7.
AG>
AG>Почему же такой древний?
AG>Сейчас Qt 5.14.2 уже идёт.

Потому и чисто теоретически, но в любом случае для графического интерфейса это был бы Qt.

Здравствуйте, c-smile, Вы писали:

S>>1. Java.
CS>Тебе ж графика нужна? Если "да" то где графика и где Java?

Не того уровня графика, о которой вы подумали.

Здравствуйте, alexzzzz, Вы писали:

A>Неочевидно. Кросс-платформенность важна и ценна, когда реально нужна.

A>1. Если пишешь для себя, а ты на Windows, то кросс-платформенность не нужна.
Если завтра я на Linux — то тогда возможно два пути:
a) — всё на кросс-платформенной базе (тот же Qt) — можно сделать версию под Linux с относительно небольшими трудозатратами;
b) — всё "гвоздями_прибито" к Windows, тогда (вангую) окажется всё проще переписать с нуля

A>2. Если пишешь для конкретно кого-то, а он/она на Windows, то кросс-платформенность не нужна.
Если есть какие-либо сторонние требования Заказчика по части GUI — тогда (возможно) придётся выбрать тот же WPF,
но при этом — согласовать с Заказчиком, что всё Windows-only.
Иначе — смотри выше.

A>3. Если пишешь для некоей целевой аудитории, и есть понимание, что они все на Windows, то кросс-платформенность не нужна.
+100500
Если есть однозначное понимание требований Windows-only — тогда совсем другое дело.

A>"Начальная ценность"
A>Это про любую фичу вообще. Вот пришла тебе в голову идея новой классной фичи — отлично, но теперь её надо будет как минимум
A>а) продумать/задизайнить,
A>б) реализовать,
A>в) протестировать,
A>г) до бесконечности поддерживать, чтоб не поломалась.

Вот в том и ценность кросс-платформенного фреймворка, что всё это (ну почти всё) будет прямо из коробки
Конечно же, я понимаю что (например) вызова WinApi напрямую не пройдут, придётся найти их POSIX аналоги.
Файловая система и пути к файлам — также возможно придётся подправить напильником.
Но это не так трудозатратно, как переделывать все с самого начала.

A>Т.е. вопрос надо ставить не как "если есть возможность, то почему нет?", а как "кому-то это вообще надо?"

Кому надо?
Сегодня — почти никому, завтра — практически всем...

S>почему нет?
Нет, потому что разработка усложняется сильно, но даст ли это сопоставимый профит?

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

draw.io, lucidchart.com не устраивают?

Есть много вариантов. Но если редактор действительно простой, то можно и на электроне, со временем выйти в веб.

Здравствуйте, CreatorCray, Вы писали:

I>>то можно и на электроне
CC>Канделябром за такое.

Работает не хуже рисовалок на дотнете или джаве.

Здравствуйте, CreatorCray, Вы писали:

I>>Работает не хуже рисовалок на дотнети или джаве.

CC>Не, нафиг. Уж лучше дотнет чем это говно. Жава тоже идёт в лес в том виде в котором она предполагается запускаться.

Единственное отличие это onPaint у дотнета. В жээсе такого нет, потому драг-дроп всегда будет рывками. Сама отрисовка ничем не отличается.

Здравствуйте, CreatorCray, Вы писали:

I>>>>то можно и на электроне
CC>>>Канделябром за такое.
I>>Работает не хуже рисовалок на дотнети или джаве.

CC>Не, нафиг. Уж лучше дотнет чем это говно. Жава тоже идёт в лес в том виде в котором она предполагается запускаться.

Экзешник хочешь? Современная джава умеет. Там проблема со стрёмным UI у Swing-а (причем хороший вроде можно то ли купить, то ли скачать, но по дефолту так), либо с Web UI у JavaFX (который не всем нравится).

Здравствуйте, vsb, Вы писали:

vsb>Экзешник хочешь? Современная джава умеет.
А он будет одним процессом или самораспакуется и запустит грёбаный зоопарк?

vsb>Когда я проследний раз использовать Qt 4, С++ там был крайне примитивный, процентов 30 от "настоящего" хардкора. Исключений нет, кодогенерация вместо шаблонной магии. В общем если тебя смущает только это — попробуй. То подмножество С++ как раз не сильно отличается от Java. Разве что сборщика мусора нет, но и на ссылках можно писать код.

Я Qt называю «.net для бедных» Потому что там тоже все свое, все реализовано с нуля, а программист тщательно оберегается от прямой работы с памятью. Помнится, когда я еще чуть-чуть знал С++, меня поразило, что можно было создать хоть миллион объектов через new, положить их на форму, например, а потом прибить саму форму и не заботиться о том, что где-то что-то осталось висящее. Так я познакомился со смартпойнтерами и счетчиком ссылок

A>Или всё так же никому, а ты упирался зачем-то. Или сегодня ты делаешь условный графический редактор, а завтра окажется, что нужно что-то другое.

Смотрю на кучу новых графических редакторов, которые появились под МакСОь, iOS, винду и даже веб (серия продуктов от Affinity, Pixelmator, Sketch, Procreate, Flow, Oilist, Figma) и сколько из них появилось под Линукс (и сравнение в качестве и количестве возможностей).

Так что да. «всё так же никому», если речь идет про Линукс. Люди делают продукты для любых других платформ. И очень редко делают их кроссплатформенными, потому что овчинка не стоит выделки.

Здравствуйте, vsb, Вы писали:

vsb>Самый настоящий экзешник, даже код прекомпилируется. Хелло ворлд весит около 6 МБ. Никакого обмана. Называется GraalVM если что.
Хм, молодцы! Серьёзный шаг.

Здравствуйте, CreatorCray, Вы писали:

I>>Единственное отличие это onPaint у дотнета. В жээсе такого нет, потому драг-дроп всегда будет рывками. Сама отрисовка ничем не отличается.
CC>Пофигу, всё равно закопать.
CC>Electron это abomination которому нельзя дать вырасти.

Электрон уже давно не единственный в своём роде. Кроме того, браузер потиху становится самостоятельной платформой и давно доминирует для определенного вида приложений.
Из этого следует, что проекты проще стартовать именно здесь. Что мы и наблюдаем.

Здравствуйте, AlexGin, Вы писали:

AG>ИМХО кросс-платформенная разработка всегда важна и ценна.

Кому именно ценны и важны? Для конторы выгоднее всего поддерживать одну версию приложения. Начинать нужно с самой массовой. Если веб в планах, то лучше начинать именно с него, т.к. на данный момент это самая массовая платформа.

AS> В остатке: пишешь под Windows на чём удобнее. Если Mac действительно окажется нужным — делаешь под него версию. Linux — всё, что с GUI не имеет смысла.

А как же главная операционная система будущего по версии Вассермана?

Здравствуйте, Ikemefula, Вы писали:


AG>>ИМХО кросс-платформенная разработка всегда важна и ценна.

I>Кому именно ценны и важны? Для конторы выгоднее всего поддерживать одну версию приложения. Начинать нужно с самой массовой. Если веб в планах, то лучше начинать именно с него, т.к. на данный момент это самая массовая платформа.

Ну а если веба в планах нет? Тем более, что ниша веба постепенно перекрывается специализированными mobile решениями...

Здравствуйте, AlexGin, Вы писали:

I>>А зачем? Твои юзеры сидят на этом линуксе?
AG>+100500
AG>Да, бывает и такое — что люди ставят условие — работа на OS Linux.
AG>Отмечу, что я занимаюсь в основном техническими и расчётными приложениями на C++

Какая доля луноходов в общей массе?

I>>Точнее — ничего. Кросс-платформенный фремворк избавит тебя от написания процентов 80% платформенно-зависимого кода.
I>>Это окупится только в том случае, если юзеры требуют разных платформ. В противном случае это будет медленнее — нативная разработка под конкретную платформу будет быстрее.
AG>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.
Экономишь время исключительно за счет:
1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
2 базовых функций нативных платформ, типа открыть-прочитать файл

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

AG>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

Именно это тебя ждет и в кроссплатформенной версии.
Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
А всё совсем не так — этот X скорее всего вообще поддерживаться не будет, вообще нигде. И тебе придется писать его везде самому.
Гы-гы.
Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности. А в теории надо бы добавить недостающую платформу. Снова гы-гы.


I>>Кроссплатформенность это никакая не фича. Как только появится веб-решение, про твою кроссплатформенную рисовалку дружно забудут.
AG>
AG>В том стеке, на котором работаю я, веб-решения совсем не просматриваются как даже "хоть_какие" решения (sorry за каламбур).

Что это за стек такой?

Здравствуйте, Ikemefula, Вы писали:

Ну я особо то не вижу засилья вэба на мобильных приложениях.
Тот же блазор например приспосабливают под Native
https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-feb-2020-update/

Но когда смотришь, что станица жрет 30-50% десктопного проца, как то сильно сомневаешься в адаптации под мобильные девайсы

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

lazarus предлагали?

Здравствуйте, Mamut, Вы писали:

M>не являются веб-технологиями, и народ уже достаточно массово избавляется от react native.
Интересно. А почему, не говорят?

Здравствуйте, Mamut, Вы писали:

I>>- чистые веб-технологии, а именно — сайт, который адаптирован под мобайл
I>>- PWA

M>После превоначального хайпа PWA откусили нишу в размере 0.0001% рынка и выползать из нее не планируют. Потому что слишком много услилий даже для простейших вещей.

Если тебе не надо железячные функции юзать, то PWA это всего лишь дополнительный файл — манифест. Всё остальное и так уже готово.

Раньше Apple тормозили процесс. Сейчас уже худо-бедно есть поддержка. Более того — есть поддержка и в Винде. Пока не сильно военные приложения, но это очень интересно.

I>>- react-native, ionic и тд

M>не являются веб-технологиями, и народ уже достаточно массово избавляется от react native.

Ужос, JavaScript, редакс, реакт перестали быть веб технологиями...

I>>- гибридные приложения, где БЛ и контент работают внури web-view

M>Таки были и есть, на победу веб-технологий это не тянет

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

I>>Нативные нужны исключительно там, где нужен доступ к железу или максимальная производительность.

M>Ну то есть везде, где надо показать больше одной простой страницы с текстом и картинками (с чем веб тоже справляется достаточно плохо).

Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

I>>>- PWA

M>>После превоначального хайпа PWA откусили нишу в размере 0.0001% рынка и выползать из нее не планируют. Потому что слишком много услилий даже для простейших вещей.

I>Если тебе не надо железячные функции юзать, то PWA это всего лишь дополнительный файл — манифест. Всё остальное и так уже готово.

Ничего там нет готового.

I>Раньше Apple тормозили процесс. Сейчас уже худо-бедно есть поддержка. Более того — есть поддержка и в Винде. Пока не сильно военные приложения, но это очень интересно.

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


I>>>- react-native, ionic и тд

M>>не являются веб-технологиями, и народ уже достаточно массово избавляется от react native.

I>Ужос, JavaScript, редакс, реакт перестали быть веб технологиями...

Да, react-native — это не веб-технологии.


I>>>Нативные нужны исключительно там, где нужен доступ к железу или максимальная производительность.
M>>Ну то есть везде, где надо показать больше одной простой страницы с текстом и картинками (с чем веб тоже справляется достаточно плохо).
I>Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

Приложения Инстаграмма и Фейсбука в разы лучше их же страниц. Количество невероятного криворукого звиздеца на странице Твиттера зашкаливает все разумные пределы: https://www.google.com/search?hl=en&q=twitter%20site%3Agrumpy.website (это малая часть, и это — сайт, которые ничего, кроме текста и картинок, не показывает)

Здравствуйте, Serginio1, Вы писали:

S>Ну я особо то не вижу засилья вэба на мобильных приложениях.

А куда ты смотришь, интересно ?

Здравствуйте, Mamut, Вы писали:

I>>Если тебе не надо железячные функции юзать, то PWA это всего лишь дополнительный файл — манифест. Всё остальное и так уже готово.

M>Ничего там нет готового.

Это вероятно особенность того, как ты ведешь разработку

I>>Раньше Apple тормозили процесс. Сейчас уже худо-бедно есть поддержка. Более того — есть поддержка и в Винде. Пока не сильно военные приложения, но это очень интересно.

M>Нет там ничего интересного. Полное говно на основе полудесятка невероятно сырых и кривых стандартов.

Ты всерьез уверен, что тебя за эталон надо брать, спрашивать чего интересно или нет? Тебе корона не жмёт?

I>>Ужос, JavaScript, редакс, реакт перестали быть веб технологиями...

M>Да, react-native — это не веб-технологии.

Не надо передёргивать — JavaScript, редакс, реакт — веб технологии. От реакт-нейтив остаётся только рендеринг и кое что еще. Всё остальное как в обычном вебе, один к одному.

I>>Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

M>Приложения Инстаграмма и Фейсбука в разы лучше их же страниц.

Итого — от тебя поступает много пены и ни одного релевантного примера. Что же лучше веба справится с простой страничкой, где смешаный контент? Пример давай, не надо ничего писать.
От тебя ожидается выхлоп вида "вот нативный рендерер + рич UI который отрендерит смешаный контент в сто раз лучше, качественнее и тд и тд"
Я, например, знаю про проекты, что замахивались на такое. Большинство из них вымерло, остатки пугают даже мимо проходящих разработчиков
Успешных реализаций всего жалкая кучка:
всевозможные web-view, где заимствованы куски движка браузера или даже браузер целиком
react-native
native-script
sciter который по факту цельный браузер

Итого — в этой области лучше веба работает только веб.

I>>>Если тебе не надо железячные функции юзать, то PWA это всего лишь дополнительный файл — манифест. Всё остальное и так уже готово.

M>>Ничего там нет готового.

I>Это вероятно особенность того, как ты ведешь разработку

Это особенность реальности.

M>>Нет там ничего интересного. Полное говно на основе полудесятка невероятно сырых и кривых стандартов.
I>Ты всерьез уверен, что тебя за эталон надо брать, спрашивать чего интересно или нет? Тебе корона не жмёт?

Я нигде не говорил, что меня надо брать за эталон.

I>>>Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

M>>Приложения Инстаграмма и Фейсбука в разы лучше их же страниц.

I>Итого — от тебя поступает много пены и ни одного релевантного примера.

Ты сам привел в пример Инстаграм, Фейсбук и Твиттер. Как только оказалось, что они не поддерживают твою точку зрения, я оказался в этом виноват, ну-ну

I> Что же лучше веба справится с простой страничкой, где смешаный контент? Пример давай, не надо ничего писать.

Ты привел три примера. Инстаграм. Фейсбук. Твиттер.

Приложения Инстаграмма и Фейсбука в разы лучше их же страниц. Страница Твиттера страдает от просто миллиона проблем, которых нет даже в их собственном убогом приложении. То есть твои же примеры подтверждают мои слова.

Здравствуйте, Shmj, Вы писали:

S>Если есть возможность кросс-платформы, скажем так, то почему нет? Прога типа простого графического редактора узкой направленности (т.е. заточен под определенную область). Как я понимаю, из кроссплатформы осталось:

S>1. Java.
S>2. QT.
S>3. Electron?

S>Еще варианты есть?

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

И немногие рисуют кроссплатформенный гуй сами, на libSDL2. Steam например.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

S>>Ну я особо то не вижу засилья вэба на мобильных приложениях.

I>А куда ты смотришь, интересно ?
На приложения на своем мобильном устройстве

Здравствуйте, Mamut, Вы писали:

I>>Это вероятно особенность того, как ты ведешь разработку

M>Это особенность реальности.

Это ты снова замахнулся на всемогущество? Ну-ну.

M>>>Нет там ничего интересного. Полное говно на основе полудесятка невероятно сырых и кривых стандартов.
I>>Ты всерьез уверен, что тебя за эталон надо брать, спрашивать чего интересно или нет? Тебе корона не жмёт?

M>Я нигде не говорил, что меня надо брать за эталон.

В таком случае ты ничего не сказал Я замечу, что сначала появляется софт, а уже потом подтягиваются стандарты. Сырость стандартов ничего не говорит — это нормальное состояние.

I>>Итого — от тебя поступает много пены и ни одного релевантного примера.

M>Приложения Инстаграмма и Фейсбука в разы лучше их же страниц. Страница Твиттера страдает от просто миллиона проблем, которых нет даже в их собственном убогом приложении. То есть твои же примеры подтверждают мои слова.

Напоминаю — от тебя требовалось показать, что же рендерит контент лучше чем браузер или его производные.
В качестве примеры ты, фактически, привел "браузер или его производные" C места и в лужу. Браво!

Здравствуйте, Serginio1, Вы писали:

S>>>Ну я особо то не вижу засилья вэба на мобильных приложениях.

I>>А куда ты смотришь, интересно ?
S> На приложения на своем мобильном устройстве

А разве речь про твоё устройство?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

S>>>>Ну я особо то не вижу засилья вэба на мобильных приложениях.

I>>>А куда ты смотришь, интересно ?
S>> На приложения на своем мобильном устройстве

I> А разве речь про твоё устройство?
Ну ты же пишешь, что оно развивается. Значит и на обычных мобильниках должны быть такие приложения.
И как он них узнать? Что то кто то где то может быть и там у него и засилье. Но вот в обычной жизни его нет

Кстати у 1С есть мобильный клиен на основе браузера. Народ как то его не ахти активно и использует

Здравствуйте, Serginio1, Вы писали:

I>> А разве речь про твоё устройство?
S> Ну ты же пишешь, что оно развивается. Значит и на обычных мобильниках должны быть такие приложения.
S>И как он них узнать? Что то кто то где то может быть и там у него и засилье. Но вот в обычной жизни его нет

А разве я сказал, что засилье или "уже на каждом смартфоне" ? Нативная апликачка стоит слищклм дорого. PWA или гибрид какой сделать гораздо дешевле.

S>Кстати у 1С есть мобильный клиен на основе браузера. Народ как то его не ахти активно и использует

А зачем вы его писали?

I>>>Это вероятно особенность того, как ты ведешь разработку
M>>Это особенность реальности.
I>Это ты снова замахнулся на всемогущество? Ну-ну.

Не надо мне приписывать содержимое твоей головы.

M>>Я нигде не говорил, что меня надо брать за эталон.

I>В таком случае ты ничего не сказал Я замечу, что сначала появляется софт, а уже потом подтягиваются стандарты. Сырость стандартов ничего не говорит — это нормальное состояние.

Я сказал то, что является реальностью. Ты понес нести чушь про «ты считаешь себя всемогущим»


I>>>Итого — от тебя поступает много пены и ни одного релевантного примера.

M>>Приложения Инстаграмма и Фейсбука в разы лучше их же страниц. Страница Твиттера страдает от просто миллиона проблем, которых нет даже в их собственном убогом приложении. То есть твои же примеры подтверждают мои слова.

I>Напоминаю — от тебя требовалось показать, что же рендерит контент лучше чем браузер или его производные.
I>В качестве примеры ты, фактически, привел "браузер или его производные" C места и в лужу. Браво!

С места в лужу — это как раз про тебя.

Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

Это — твои слова. Ну что ж. Возьмем эти три примера. Благо, ты их и привел. Оказывается, что приложения ФБ и Инстаграмма в разы лучше из же сайтов. А про Твиттер можно просто умолчать, потому что их сайт убог до невозможности и приложение самого твиттера (тоже весьма убогое) в разы лучше их же сайта.

То есть ты с ходу привел три примера, которые подтверждают мои слова. Молодец

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

I>>> А разве речь про твоё устройство?
S>> Ну ты же пишешь, что оно развивается. Значит и на обычных мобильниках должны быть такие приложения.
S>>И как он них узнать? Что то кто то где то может быть и там у него и засилье. Но вот в обычной жизни его нет

I>А разве я сказал, что засилье или "уже на каждом смартфоне" ? Нативная апликачка стоит слищклм дорого. PWA или гибрид какой сделать гораздо дешевле.

Да нет. На том же Андроиде без проблем все это пишется пишется. Для яблока свое. Тот же ксамарин как правило используют единый код но разный Гуй.
Хотя Xamarin.Forms и развиваются, но уж слишком много отличий.

S>>Кстати у 1С есть мобильный клиен на основе браузера. Народ как то его не ахти активно и использует

I>А зачем вы его писали?
Это 1С продвигает мобильного клиента. Я им не пользуюсь.

Здравствуйте, Mamut, Вы писали:

M>>>Это особенность реальности.
I>>Это ты снова замахнулся на всемогущество? Ну-ну.

M>Не надо мне приписывать содержимое твоей головы.

Я пишу о том, что наблюдаю разными способами. Вижу, что спрос на x,y,z вырос — о том и пишу. Вижу что софтин X,Y,Z стало больше — о том и пишу.
Но тут появляешься ты с аргументом "в реальности все иначе"
То ли ты в демагогию полез с намеком, что мои наблюдения ничего не значат
То ли во всемогущество — типа настоящая реальности известна только тебе
Выбирай сам, что тебе ближе.
По факту — аргументов по существу у тебя нет.

M>Я сказал то, что является реальностью. Ты понес нести чушь про «ты считаешь себя всемогущим»

Откуда же тебе знать про всю реальность целиком взятую? Заявка вида "что является реальностью" и есть или всемогущество, или демагогия.
Как ни крути — аргументов по существу у тебя нет.

I>>Напоминаю — от тебя требовалось показать, что же рендерит контент лучше чем браузер или его производные.
I>>В качестве примеры ты, фактически, привел "браузер или его производные" C места и в лужу. Браво!

M>

M>Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

M>Это — твои слова. Ну что ж. Возьмем эти три примера. Благо, ты их и привел. Оказывается, что приложения ФБ и Инстаграмма в разы лучше из же сайтов.

Именно. И в качестве примера "лучше веба" ты привел сам же веб, завернутый в крафтовую бумагу

Здравствуйте, Serginio1, Вы писали:

S>Да нет. На том же Андроиде без проблем все это пишется пишется. Для яблока свое. Тот же ксамарин как правило используют единый код но разный Гуй.
S>Хотя Xamarin.Forms и развиваются, но уж слишком много отличий.

Что на чем пишется? На кой ляд люди вставляют в софтину браузер или его производные?

I>>А зачем вы его писали?
S> Это 1С продвигает мобильного клиента. Я им не пользуюсь.

Вот дураки 1С, не в курсе дел...

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

S>>Да нет. На том же Андроиде без проблем все это пишется пишется. Для яблока свое. Тот же ксамарин как правило используют единый код но разный Гуй.
S>>Хотя Xamarin.Forms и развиваются, но уж слишком много отличий.

I>Что на чем пишется? На кой ляд люди вставляют в софтину браузер или его производные?
Это типа гибридных Ionic, Cordova? Сейчас о них ничего не слышно.

I>>>А зачем вы его писали?
S>> Это 1С продвигает мобильного клиента. Я им не пользуюсь.

I>Вот дураки 1С, не в курсе дел...
Они как раз много вложились в Вэб Клиента что бы и на яблоке и на линуксе и на мобильных. Но как то это не особо используется. Все сидят на вин и тонких клиентах, а мобильные решения либо RDP либо сторонние

I>Как ни крути — аргументов по существу у тебя нет.

Говорит мне человек, чьим аргументом является «ты считаешь себя всемогущим» ну-ну

M>>Это — твои слова. Ну что ж. Возьмем эти три примера. Благо, ты их и привел. Оказывается, что приложения ФБ и Инстаграмма в разы лучше из же сайтов.

I>Именно. И в качестве примера "лучше веба" ты привел сам же веб, завернутый в крафтовую бумагу

Угу. Нативные приложения, в которых веб отсутсвует, внезапно является «вебом, завернутым в крафтовую бумагу».

Здравствуйте, Ikemefula, Вы писали:

I>Какая доля луноходов в общей массе?

Большая, если твой дом на Луне...

AG>>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

I>Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.

...я никогда и не искал вакансию экономиста...

I>Экономишь время исключительно за счет:
I>1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
+100500
I>2 базовых функций нативных платформ, типа открыть-прочитать файл
+100500
I>Исключительно эта часть у тебя будет в одном экземпляре.
Эта часть — да в одном.

I>Всё остальное — по числу платформ и это в лучшем случае, т.к. могут быть нюансы, по нескольку версий в зависимости от возможностей какого нибудь иос.

Ну здесь не совсем так:
a) При разработках на C++ Qt5 для Windows/Linux львиная доля окошек (ну скажем — обычных окон) — также один экземпляр.
b) Те же многопоточные решения — закрываются на Qt и не требуют от меня копания в потоках исполнения конкретной OS.
c) Для всяких там iOS не в курсе, ими не занимался.

AG>>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

I> Именно это тебя ждет и в кроссплатформенной версии.
I>Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
...уже упоминал, что на Маке ничего не делаем...

I>Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
Про идеальный — никто и не говорит. Просто — достаточно хороший (в меру качественный).

I>Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
I>Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
I>Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
I>Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
I>Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Выше описана проблема архитектуры — что надо было выносить на уровень business logic, а что оставить в "реализационно-техническом слое".

I>Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности.

Тут вопрос в другом: что это за прога и насколько адекватные (для этой задачи) были её разработчики?

I>А в теории надо бы добавить недостающую платформу.
А в практике — хорошо продумать архитектуру проекта, чтобы потом не ломать...

Вот тут-то и думается, что книга GoF и другие книжки по паттернам проектирования — обязаны быть нашей настольной литературой.
Да, и с книгами Александреску дружить нужно!
Это очень важно для любых разработок, даже если пишем всё для одной платформы.

I>Что это за стек такой?

Технологические программы, управление в специализированных системах, расчёты и моделирование.
Ранее я много занимался SCADA и MES системами (это отдельное направление).
В общем, там где применение C++ сам Бог послал.

Здравствуйте, Mamut, Вы писали:

I>>Как ни крути — аргументов по существу у тебя нет.

M>Говорит мне человек, чьим аргументом является «ты считаешь себя всемогущим» ну-ну

Сколько тебя помню, твои любимые аргументы вида я знаю лучше | больше | правильнее. Сейчас вот новый добавился — "я знаю реальность".

Чего ты ждешь в ответ на такие аргументы? Что собеседники падут ниц услышав такое заявление, начнут соглашать с тобой?

I>>Именно. И в качестве примера "лучше веба" ты привел сам же веб, завернутый в крафтовую бумагу

M>Угу. Нативные приложения, в которых веб отсутсвует, внезапно является «вебом, завернутым в крафтовую бумагу».

Да ты я вижу в теме. Смотри, гибридное приложение на основе in-app браузера:

https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/
https://github.com/macliu010/android_facebook_decomplied/tree/474c0767eea6369444aa630ec8c3d3722b062bd1/app/com/facebook/katana/webview
https://developer.android.com/reference/android/webkit/WebView

I>Сколько тебя помню, твои любимые аргументы вида я знаю лучше | больше | правильнее. Сейчас вот новый добавился — "я знаю реальность".

Опять ты придумываешь за меня содержимое твоей головы

M>>Угу. Нативные приложения, в которых веб отсутсвует, внезапно является «вебом, завернутым в крафтовую бумагу».

I>Да ты я вижу в теме. Смотри, гибридное приложение на основе in-app браузера:

I>https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/

Both Facebook's Android app as well as Facebook's iOS app use a so-called in-app browser, sometimes also referred to as IAB.

Ikemefula: Facebook — это веб в обертке аааа!!!



I>https://github.com/macliu010/android_facebook_decomplied/tree/474c0767eea6369444aa630ec8c3d3722b062bd1/app/com/facebook/katana/webview

Неужели, в приложении где-то используется webview. Дальше что? Из этого следует, что facebook — это обертка для веба? Нет, даже близко этого не следует. Fb использует WebView для того, чтобы показать веб-контент. Например, если в приложении ткнешь в ссылку, то откроется не Safari/Chrome, а WebView внутри приложения. Местами настройки тоже вызывают WebView.

На этом «обертка веба» в Фейсбуке, по сути, заканчивается. Все остальное — нативное приложение.

Самое смешное в твоем «аргументе», опять, то что твой «аргумент» опять поддерживает мою точку зрения, а не твою. Ну и то, что из всего декомпилированного кода фейсбука ты выбрал самую малую часть, интеграцию WebView, и полностью проигнорировал весь остальной код, который WebView не использует — ui, dialog, все view кроме одного, практически все activity и т.п., которые все, за исключением одной-двух фич, являются нативными.

ЗЫ. У нас в приложении тоже WebView используется в паре мест. Из-за этого недавно багу искали четыре дня двумя командами. Пойду, расскажу чувакам, что из-за этого их приложение перестало быть нативным, а является лишь «вебом, завернутым в крафтовую бумагу». Пусть посмеются.

Здравствуйте, Mamut, Вы писали:

I>>Сколько тебя помню, твои любимые аргументы вида я знаю лучше | больше | правильнее. Сейчас вот новый добавился — "я знаю реальность".

M>Опять ты придумываешь за меня содержимое твоей головы

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

M>>>Угу. Нативные приложения, в которых веб отсутсвует, внезапно является «вебом, завернутым в крафтовую бумагу».

I>>Да ты я вижу в теме. Смотри, гибридное приложение на основе in-app браузера:

I>>https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/

M>

M>Both Facebook's Android app as well as Facebook's iOS app use a so-called in-app browser, sometimes also referred to as IAB.

M>Fb использует WebView для того, чтобы показать веб-контент.

Именно — веб вью для показа веб контента. И запрос был именно такой. А ты утверждал, что веб там вообще нет

M>Самое смешное в твоем «аргументе», опять, то что твой «аргумент» опять поддерживает мою точку зрения, а не твою.

Читаем некоего Mamut:
"Нативные приложения, в которых веб отсутсвует, " @ Mamut
"Fb использует WebView для того, чтобы показать веб-контент. " @ Mamut

Ты определись, отсутствует, или присутствует. А то возникло ощущение, что у тебя каждое из них есть общий случай другого

>Ну и то, что из всего декомпилированного кода фейсбука ты выбрал самую малую часть, интеграцию WebView, и полностью проигнорировал весь остальной код, который WebView не использует —

Смотри выше, свои же слова. Я показал гибридизацию и нигде не утверждал, что весь UI сделан на WebView.

I>"Нативные приложения, в которых веб отсутсвует, " @ Mamut
I>"Fb использует WebView для того, чтобы показать веб-контент. " @ Mamut

Таймлайн: нативный
Страницы и группы: нативные
Видео и watchlist'ы: нативные
События: нативные
Поиск(от поиска людей до поиска событий на карте): нативный
Фотографии: нативные
Нотификации: нативные
Офферы, донаты, покупки: нативное
Создание и редактирование новых постов: нативное
...
В посте есть ссылка на веб-страницу, кликнул на нее, открылся WebView

Ikemefula: Ага! Фейсбук — всего лишь сам же веб, завернутый в крафтовую бумагу!


I>Смотри выше, свои же слова. Я показал гибридизацию и нигде не утверждал, что весь UI сделан на WebView.

Ikemefula: что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

Mamut: Приложения Инстаграмма и Фейсбука в разы лучше их же страниц.

Ikemefula: Итого — от тебя поступает много пены и ни одного релевантного примера. Что же лучше веба справится с простой страничкой, где смешаный контент

Mamut: Ты привел три примера. Инстаграм. Фейсбук. Твиттер. Приложения Инстаграмма и Фейсбука в разы лучше их же страниц.

Ikemefula: И в качестве примера "лучше веба" ты привел сам же веб, завернутый в крафтовую бумагу

Только вот незадача. Эти приложения — не «веб, завернутый в крафтовую бумагу». И когда тебя тыкаешь в это носом, ВНЕЗАПНО «Я показал гибридизацию и нигде не утверждал, что весь UI сделан на WebView.» Там даже гибридизации нет. Ссылки на сторонние веб-сайты открываются в WebView (как и предполагается). Они даже окончательно перевели настройки в нативное приложение, сейчас проверил (раньше некоторые настройки открывали WebView).

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

Здравствуйте, Mamut, Вы писали:

M>Только вот незадача. Эти приложения — не «веб, завернутый в крафтовую бумагу». И когда тебя тыкаешь в это носом,

У тебя какая то постоянная потребность кого то тыкать носом. Может тебе к специалисту сходить?

>ВНЕЗАПНО «Я показал гибридизацию и нигде не утверждал, что весь UI сделан на WebView.» Там даже гибридизации нет. Ссылки на сторонние веб-сайты открываются в WebView (как и предполагается). Они даже окончательно перевели настройки в нативное приложение, сейчас проверил (раньше некоторые настройки открывали WebView).

Они написали целый вагон кода, что бы показывать сторонние сайты? Не смеши. Для этого не надо ничего такого. Хтмл контента гораздо больше.

M>И эти нативные приложения справляются с задачей «показать простую страничку, где смешанный контент» в разы лучше, чем веб.

Простую страничку показывает именно WebView, ты сам об этом и пишешь. Сами они рендерят контент из json. А вот html — естественно WebView. Вот и все что я тебе хотел сказать. Возможно, что они WebView гораздо меньше используют, ну и что с того?

I>Они написали целый вагон кода, что бы показывать сторонние сайты? Не смеши. Для этого не надо ничего такого. Хтмл контента гораздо больше.

Что ты несешь. Они не писали вагон кода, чтобы показывать сторонние сайты. Они написали вагон кода, чтобы показывать свой контент. Потому что для показа своего контента нативное приложение в разы лучше веба.

M>>И эти нативные приложения справляются с задачей «показать простую страничку, где смешанный контент» в разы лучше, чем веб.

I>Простую страничку показывает именно WebView

Потому что Фейсбук не подписывался показывать контент всего веба.

I> ты сам об этом и пишешь. Сами они рендерят контент из json. А вот html — естественно WebView. Вот и все что я тебе хотел сказать. Возможно, что они WebView гораздо меньше используют, ну и что с того?

Отлично как «фб и прочи — это всего лишь обертка для веба» превратилось в «ой нет, я всего лишь хотел сказать про html».

что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

«С простой страницей типа инстаграма, фейсбука, твиттера» лучше справляются:

— инстаграм: нативное приложение инстаграма
— фейсбук: нативное приложение фейсбука
— твиттер: нативное приложение твиттера (или любое 3rd-party приложение для твиттера)

Здравствуйте, Mamut, Вы писали:

I>>Они написали целый вагон кода, что бы показывать сторонние сайты? Не смеши. Для этого не надо ничего такого. Хтмл контента гораздо больше.
M>Что ты несешь. Они не писали вагон кода, чтобы показывать сторонние сайты. Они написали вагон кода, чтобы показывать свой контент. Потому что для показа своего контента нативное приложение в разы лучше веба.
Ну вот есть Slack. У них внутри Electron, т.е. фактически нативный web. При этом оно более отзывчивое и быстрое, чем большинство обычных десктопных приложений.

Я скорее склоняюсь к тому, что в FB у программистов руки кривые, а денег много.

M>>Что ты несешь. Они не писали вагон кода, чтобы показывать сторонние сайты. Они написали вагон кода, чтобы показывать свой контент. Потому что для показа своего контента нативное приложение в разы лучше веба.
C>Ну вот есть Slack. У них внутри Electron, т.е. фактически нативный web. При этом оно более отзывчивое и быстрое, чем большинство обычных десктопных приложений.

C>Я скорее склоняюсь к тому, что в FB у программистов руки кривые, а денег много.

В Слаке ровно ноль функциональности по сравнению с ФБ. Как только они пытаются что-то навертеть сверху, как прекрасные веб-технологии тут же ломаются нахрен. См. их новый редактор текста, который он уже несколько месяцев нормально починить не могут.

А так да. Показать совсем простую страницу с текстом и картинками веб может.

Здравствуйте, Mamut, Вы писали:

C>>Я скорее склоняюсь к тому, что в FB у программистов руки кривые, а денег много.
M>В Слаке ровно ноль функциональности по сравнению с ФБ. Как только они пытаются что-то навертеть сверху, как прекрасные веб-технологии тут же ломаются нахрен. См. их новый редактор текста, который он уже несколько месяцев нормально починить не могут.
В Слаке есть поиск, динамический рендеринг встроенных документов, умение отображать на порядок больше контента, чем FB.

M>А так да. Показать совсем простую страницу с текстом и картинками веб может.
Ровно то, что делает FB.

M>>В Слаке ровно ноль функциональности по сравнению с ФБ. Как только они пытаются что-то навертеть сверху, как прекрасные веб-технологии тут же ломаются нахрен. См. их новый редактор текста, который он уже несколько месяцев нормально починить не могут.
C>В Слаке есть поиск, динамический рендеринг встроенных документов, умение отображать на порядок больше контента, чем FB.

Все функции в слаке раскиданы в отдельные, непересекающиеся сущности. Поиск сам по себе. Ввод текста сам по себе. Меню само по себе. Дилоги сами по себе и т.п.

А главное окно — это текст + картинки без какой-либо сложно структуры или функционала. Всё.

Здравствуйте, Mamut, Вы писали:

M>«С простой страницей типа инстаграма, фейсбука, твиттера» лучше справляются:

M>- инстаграм: нативное приложение инстаграма
M>- фейсбук: нативное приложение фейсбука
M>- твиттер: нативное приложение твиттера (или любое 3rd-party приложение для твиттера)

Ну ок, ты меня уел. Тебе стало спокойнее? Очевидно, что ты взял себя в руки и выдал адекватные аргументы а не твоё любимое "я лучше знаю!!!"

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mamut, Вы писали:

M>>«С простой страницей типа инстаграма, фейсбука, твиттера» лучше справляются:

M>>- инстаграм: нативное приложение инстаграма
M>>- фейсбук: нативное приложение фейсбука
M>>- твиттер: нативное приложение твиттера (или любое 3rd-party приложение для твиттера)

I>Ну ок, ты меня уел. Тебе стало спокойнее? Очевидно, что ты взял себя в руки и выдал адекватные аргументы а не твоё любимое "я лучше знаю!!!"

Первое же мое сообщение:

https://rsdn.org/forum/flame.comp/7708288.1

Автор: Mamut
Дата: 16.04.20

I>Нативные нужны исключительно там, где нужен доступ к железу или максимальная производительность.

Ну то есть везде, где надо показать больше одной простой страницы с текстом и картинками (с чем веб тоже справляется достаточно плохо).

Второе мое сообщение:

I>Ок, что же лучше веба справится со простой страницей типа инстаграма, фейсбука, твиттера? Пример в студию.

Приложения Инстаграмма и Фейсбука в разы лучше их же страниц. Количество невероятного криворукого звиздеца на странице Твиттера зашкаливает все разумные пределы: https://www.google.com/search?hl=en&q=twitter%20site%3Agrumpy.website (это малая часть, и это — сайт, которые ничего, кроме текста и картинок, не показывает)

... (сообщения с третьего по шестое повторяют это же несколько раз)
...

Седьмое мое сообщение

https://rsdn.org/forum/flame.comp/7709367.1

Автор: Mamut
Дата: 17.04.20

I>"Нативные приложения, в которых веб отсутсвует, " @ Mamut
I>"Fb использует WebView для того, чтобы показать веб-контент. " @ Mamut

Таймлайн: нативный
Страницы и группы: нативные
Видео и watchlist'ы: нативные
События: нативные
Поиск(от поиска людей до поиска событий на карте): нативный
Фотографии: нативные
Нотификации: нативные
Офферы, донаты, покупки: нативное
Создание и редактирование новых постов: нативное

Восьмое мое сообщение

https://rsdn.org/forum/flame.comp/7709722.1

Автор: Mamut
Дата: 18.04.20

«С простой страницей типа инстаграма, фейсбука, твиттера» лучше справляются:

— инстаграм: нативное приложение инстаграма
— фейсбук: нативное приложение фейсбука
— твиттер: нативное приложение твиттера (или любое 3rd-party приложение для твиттера)

Ikemefula: Очевидно, что ты взял себя в руки и выдал адекватные аргументы



Прекрасно показывает уровень твоей адекватности, да.