Чому збочення на Electron стали нормою?

Якщо замислитися, то використання HTML + CSS + JavaScript для написання програм це цілковите безумство і черезжопство адже вони створені для оформлення тексту. Особливим чрезжопством це видається якщо згадати про те що вже 100 років як в якому-небудь Delphi можна однією рукою накидати програму з GUI. Аргумент про багатоплатформенність для мене виглядає малопереконливо тому що є той же Qt і Java яка один раз написана і запускається скрізь; Pidgin, Cherrytree, Qbittorrent, Netbeans і т.д. запускаються і працюють однаково що під Windows що під GNU/Linux. Що з нами стало? Пластмасовий мір побєділ?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному3
LinkedIn

Найкращі коментарі пропустити

~2 роки назад треба було зробити для клієнта десктоп додаток. Вибрали електрон, тому що:

— Всі демо Qt які я бачив виглядали так ніби їх робили студенти за їжу
— Фронт девів в 10 раз більше чим Qt
— За Qt треба платити

Інших альтернатив особливо і нема. Проект зробили, клієнти супер задоволені. Один з найшвидших наших проектів.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
users
will
never
create
DEMAND
for
better
software
you
have
to
fucking
CHOOSE
DISCIPLINE
to
create
it

twitter.com/...​tatus/1209903349870387200

Що з нами стало? Пластмасовий мір побєділ?

Пластмасовий мір побєділ = вопрос и есть ответом. Если платят за изобретение колеса — тебе его изобретут, здаврого смысла зачастую в решениях 0, есть бизнесс интересы, клиенты верят исполнителям, исполнители видя что «лезет» — пихают дальше... Что бы еще более понятно было — поищите ответ на вопрос — почему python пробился в админство и в админстве забили на perl.... Эх олдскулл.... Скучаю за ним.

Взагалі не в темі. Нічого не знайшов.

Многие считают и считали что perl сложный, не читабельный и все такое. Perl развивало сообщество людей, которые что то понимали и понимают в системном программирование, в низкоуровневых процессах, знакомы не по наслышке с C, C++, Asm. ПОтому для среднестатистического вайтишника — это было «сложно». Различные предложения в perl репу (cpan) принимались неоходтно и нужно было подготовить качественный perldoc и вообще пройти некоторое кол-во мытарств, что бы твой код приняли в общак. Как итоге — те кто понимаю (понимали) perl — знали что все унифицированно и круто. В свое время начал себе такой развиваться гугл, да и решил гугл приянть к себе на работу и под своим крылом развивать python, он был прост, легок в обучении, а создаель python работал в гугле. Потом с какого то перепугу дропбокс решил запедалить свой сервис на python, они пошли еще дальше — так как python не было под мобильые платвормы, запилили jPython... То есть — пошло изобретение колес. Ларри Уол не работал в гугл, или в какой то другой мега конторе и его детище развивалось профиками в среде профиков. Но увы и ах — дилетанты как всегда оказались проворнее, потому Perl так и не перешагнул 5.7, а python вместе со всем хайповым попер вверх. Дабы скрыть некоторую схожесть (спзиженность) моментов у python из perl, perl загнали так глубоко — как тольком могли....
PS вышенаписанное — имхо, не призванное сравнивать два языка, а просто маленькая история как одни технологии вытесянются другими за счет понтов и связей, а действует это глобально и на всех. Так же хрень имхо и с стеком от топикстартера, ненавижу весь фронтовый стек с его глюками, багами и отсутствием профи в комьюнити стейка фронтовых технологий. Как результат приходится долго / не долго трахомудится с бубном, что бы решить сборку проекта, деплой и прочие моменты.

У перла объективно была проблема читаемости и поддерживаемости кода, на нём написанного. Я понимаю, что на перле можно было писать как на нормальном языке, но многие предпочитали городить адовые нечитаемые однострочные конструкции.

это вот и есть та «загадка» любого ЯП
почему, как он подталкивает писать код вот так, а не иначе

Пайк вот с Go подошел к решению этого вопроса — в лоб. Может топорно, не суть.

в CS же об этом не думают. «математики» ж.

на перле можно было писать как на нормальном языке

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

Ой чую быть срачу :D :D :D

адовые нечитаемые однострочные конструкции.

которые позволяли админам и системщиккам парсить, менять, чистить, удалять и прочие штуки делать с выводом и обраоткой информации. Это одна из фишек перла, которой нифига нет в других скриптовых языках, в такой мощной реализации. Есть еще awk, sed со своими «приколами». Если педалишь сайт на перле, как по мне — там сложно написать нечитаемо, но можна, в противовес если ты педалишь обработку какую то — то тут сложно написать так — что бы тебя понял девственный мозг :) Никто же говорит про «нечитаемость» на асме, или изучении кода — при дизассемблировании, как по мне это из этой же части. Погнало массовое упрощение пилить и создание технологий которые призваны упрощасть, в итоге нее...ческий зоопарк... Хотя многие задачи можна решить не прибегая к изобретениям велосипедов...
PS — когда начинал для себя изучать python, лет так 5 назад, столкнулся с диким трешаком (для меня) — онлайн уроки подписался, где лектор рассказывал про прелести python для сисадминов, и как пример приводил скрипт по переименованию файлов, типа бысттро и красиво можна взять и запили, этим вызвали приступ ржачки -т.к., подобные вещи вообще не создавая файл можна сделать, тогда у меня впервые возникла мысль — что опыт штука мощная, а некоторые просто не вкурсе что было или есть в базовом арсенале Linux для подобных задач, по этому изобретают велосипед (сами того не зная) и рассказывают как это круто.

С дуру можна и х...й сломать :) В те лихие времена было много чудаков, которые научившись писать ересь — пихали ее везде, из разряда (2004 год, писссец мля .... ) :
www.linux.org.ru/forum/admin/567638

таки да, согласен... Но в мои лихие, С и С++ изучали в институте, а перед ними паскаль, бейсик, писали лабы, экзамены. Ломали копья на тему у кого будет быстрее код работать, чище и прочее прочее. Мне кажется что сейчас даже не многие поймут откуда это пошло «пластмассвоый мир» . Но блин — было же круто тогда... А сейчас — «у нас мега компания, нам надо задеплоить прилоежние на php, мы используем aws, gc....» бэ...
С и сейчас для меня эталон мощности и красоты, который в правильных руках поможет создать Давида, а в неправильных — банан, из современного искуства... Хотя я уже ни С, ни С++, ни Асм, ни паскаль лет даже не знаю сколько не юзал и уже не помню, помню только что было круто :) ...

Дропбокс, как я уже писал — взял и от нех...й делать запилил jPython и вообще весь проект на одном языке. Я давно их сервис не юзал, но когда то настраимвал людям бекап в дропбокс, на линуксе, это выглядело дико убого со стороны дропбокса с их паской кода на питоне. Так что дешевле — дороже, имхо не канает, а канает круче, хайповее, моднее. То же касается AWS, GC и других клауд платформ. где затраты в 10 раз выше средей стоимости того же, в своей реализации, но почему то юзают клауд провайдеров.

Вы не поняли суть моего поста, или я вас. По вашему нанять разрабов на разработку языка программирования — это оптимизация ? Я как то слабо верю в то, что задачи заложенные в DropBox нельзя было решить готовыми на тот момент решениями, я вот сталкивался где то в 2015г. Вопрос не в полторы каллеки, а в том, что сейчас приянто считать что «нет мира за пределом JS/PHP/Python». Хотя мир есть, есть ембед разработка, херово в Украине с ней — но она и у нас есть, есть низкоуровневая разработка, есть на перл разработка — просто не в тех масштабах, потому что есть компании — которые вагонами вкидывают бабло в развитие своих стеков, своих платформ. как результат — люди делают выводы:

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

и как итог — с минимальным бюджетом, с минимальным пониманием тенологий — но с наличием пары — тройки светлых умов, без оптыта — пилятся проекты с использованием технологий, которые ведут к диким прайсам во всех направлениях, как итог проекты загибаются.
Дабы не быть голословным CGI
kytoon.com/sutra-tds.html
Написано на С по моему или плюсках, клиенту поднимал систему эту (покупали) я с разработчиком перескался и вообще с его продуктами познакомился году так в 2009, его продукты так и живут, так и продаются и так и работают на любой современной ОС, тянут неебическую нагрузку.
Проблема не в языке — а в опыте и знаниях. На данный момент меня никто не убедил или заставил своими доводами задуматься об обратном.

Я не беизнесмен — технарь. Потому для меня является неадекватростью:

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

Так как люди должны думать головой, даже если у них сейчас есть деньги и вкладывать в понты — тупость.

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

Потму и возник этот пост у ТС — потому как упоротость торжествует над здравым смыслом.

смотря за что мы говорим, но в целом это более-менее реальная картина, добавьте сюда остальные поплуярные яп из тиоби, а именно жабу, плюсы, шарп и получаем покрытие чуть ли не всего пространства(около 80%).

ХЗ, ХЗ — не все то так и прямолинейно, например сейчас помогаю конторе одной — у них на расчетный обьем данных 64Тб и слабый траф — нет хайповых технологий, хотя и контора заказчик миллионер, платит как я понял оооочень хорошо. Все же есть еще в нашем мире те — кто ценит качество, а не понты :)

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

А какая перспектива от jPython в мобильной разработке ? Уже как бы лет 5 пргошло как я про это читал в статье, где у упоением школьник рассказывал, как они запилили проект на одном ЯП и свой приудмали что бы ниче не менять...

чесно- все с кем сталкивался, работал и AWS — потому что это по их мнению,повышает престижность компании, проекта. То есть фактичски в 10 раз переплачивали, хотя проще было бы в рекламу вложится. вВсе же тут останусь при своем мнении, тут нет подстегивания эконмики, это раздувание пузыря.

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

Я из тех — кто ищет проекты, не входящие в эти 80% и скажу вам до 15 года это было золоте время, сечас я поддался фетишу с калудами, девомпами и продался в эту область, но устал от нее — веду переговоры с оной вроде как неебически крупной конторай — грозится что для меня у них есть непаханное поле, вот надеюсь не облажаться по софт. скилам (ненавижу бля софт склиы). Это мой фетиш — пдеалить то, что другие сдались, не тянут, там где жопа, разгребать с матами и кофем суткими, получать кайф от решения проблем и задач своего направления, а не выгорять от всякого рода мозгодрюканья — как собрать эьтот ебу..чий фронт стек, что бы он в докере работал корректно, потому как фронті напедалили кода, а как собирать никто из них не понимают...

это надо не у меня спрашивать, я говорил в целом про переход на питон с перла.

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

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

ХЗ, пару лет назад запилили с клиентом партнерку по облачному майнингу, нам она обошлась где то в 600 евро в месяц, по моим прикидкам в Амазоне это стоило бы нам под 10к если EC2, если Лямбда — то я даже боюсь представить себе... Так же пилили проекты для рекламщиков высоконагруженный и стабильные — то же на дедиках, точно знаю что за подобную систему в Амазоне конкуренты платили около 7к долларов, мы около 200 евро, наша система до сих пор работает, уже года 4 наверное тьфу тьфу тьфу. Я вот и пытаюсь понять — где у меня перекос, или может я задчи не ловил такие — что бы протащится от Амазона или GC. Но нытья от клиентов про дороговизну наслушался и просбы пересмотреть затраты что бы снизить прайс.

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

да нет у вас перекоса.

просто механика бизнеса — снизить риски от бас фактора

но за все надо платить — решили увеличить надежность с помощью избавления зависимости от эксперта — платите экспертам в лице «AWS»

Но нытья от клиентов про дороговизну

это да, ноют.
но платить то им все равно кому-то придется, или AWS, или вам.
так что кивайте сочувственно головой, а свои выгоды от ситуации — не упускайте :)

Амазон дорогой и очень

да, цена вполне оправдана

вопрос только в том — а надо ли это все для конкретного проекта, даже с учетом перспектив развития на 3 года вперед?

общего ответа нет, и быть не может.

но нередко, а может и в большинстве случаев:

«кто-то не тот купил что-то не то» как говоривал один мой шеф о клиентах купивших дорогущее решение, потому что сейлзы решения тоже не просто так хлеб едят,

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

то и ноет потом такой клиент, причитает.

Ровно так же как и другие провайдеры подобных услуг, DO за пару недель присылает уведомление о работах и о том что потушат сервак, online.net могут уронить и неделю поднимать свой клауд с индусским саппортом хочется выстрелить сбее к глаз, AWS при использовании ALB — я все равно периодами получаю уведомления о недоступности проекта по таймауту, или бекенд отваливается от ALB, да кроткосрочно, да это может отдельные регионы мира лажают, но это есть. Так же как и непонятные зависания EC2 на полном ходу... Так что имхо Амазон, как и другие находятся на ± в одном уровне доступности. А вот от S3 я кайфую :) так как не научился делать хранилища обьемные, тут ни дать ни взять на данный момент. :)

где у меня перекос, или может я задчи не ловил такие — что бы протащится от Амазона или GC

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

Затем, в ряде случаев бывает важно запустить продукт на рынок как можно быстрее. И получается оправданнее платить Амазону, чем тратить месяцы на поиск квалифицированного infrastructure engineer, который всё соберёт и настроит на dedicated servers.

да сталкивался, просто есть опыт масштабирования на дедиках того же Хетзнера, когда с 10 дедиков поднялись за сутки к 50, а потом до 100 и все это было сделано быстро. В итоге даже если нагрузка падает, ты все равно в плюсе, хоть и платишь не почасовку — а месяц минимум, так как 100 дедиков на пике обошлись по ~30 евро от хетзнера, и похер все было что один — два месяц заплатили по ~3к евро им, пока перло, при этом такой пик в калуде обошелся бы старшно представить во сколько, если учесть что у нас каждый сервак был 32Гб памяти и 8 ядер :) и было продолжительностю месяца два... Есть же решения и их куча для того — что продается как сервис, да и все равно математика не утешительная — нанять современного клауд инженера — стоит денег, заплатить за клауд — дорого, дорого * дорого = дорого в квадрате, в противовес классическим решениям нанять по средней цене спеца, купить недорого серваки — настроить быстро с использованием того же как я делал docker + ansible, ДЦ дают плавающие ip, можна воткнуть несколько серверов для балансировки и.т.д... Юзал я все то же но в амзаоне, все равно были проблемы с сеткой, с подключениями, не всегда вина Амазона, есть еще куча факторов...

в целом, как по мне — многие проекты являются зложниками неопытности, это как я приводил пример — когда лекор по python показывает скрипт на условных 15 строк кода, которые менят имеа файлов в каталоге, когда эта задача решается вообще без привлечения python. Из своего опыта могу еще таких прмеров привести немало. Не все проекты в мире размером с ФААНГ — на который монгие так яростно драконят, не все в ФААНГ круто, в том же AWS много убогости в реализации, но люди за незнанием — неимением юзают, не все у Google круто — кривости хватает и у них, как и в FB, если кто глубже работал с их сервисми или есть с чем сравнить — понимают что ах и увы, реализации в ТОП конторах страдают, очень в некоторых местах....

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

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

Ну вот он свою нишу и занял, соответствующую. Что не так? :)

Никто же говорит про «нечитаемость» на асме

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

Ну вот он свою нишу и занял, соответствующую. Что не так? :)

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

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

Почему то все противники perl -выдают одно и то же, нечитабелный, сложный, с юникод проблема, Асм тут как пример что перл не один такой, а в целом весь вопрос в опыте. Опять же — асм нужен для дизассембелров, я вот изредка но балуюсь, лажу на сайт каспера, взять какой нить exe для лома и не только у каспера. Оно вроде как и не надо — но иногда мозги разминать надо, это в работе помогает. Так что весь вопрос в опыте, знаниях и желании изучать не только новое — но и старое, так как многое новое — базхируется на старом. ПОтому и учили нас с бейсик а- паскаля и дальше уже до SQL через муки перла и сей с асмом, про физику сетей промолчу :)

>вони створенi для оформлення тексту
Як там, в 2002? CSS і JS давно вже вийшли за межі простого оформлення тексту.

Веб стак легкий для використання, дуже гнучкий, дешевий i ефективний, нема жодної причини використовувати щось інше.

только вот оно жрет память как не в себя и лагает при этом.. А казалось бы, список контактов и чатик..

На память всем плевать, лагает только на калькуляторах. Если бизнес успешно работает и продукт выполняет свою функцию, то все эти «лагает» и «збочення на Електроні» значения не имеют. Собаки лают, караван идёт, реактогоспода рубят бабки.

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

именно.
свернули кормежку
потому что и за 5 лет
не осилили бы ручную оптимизацию

ждем достижений CS конечно, слышу я регулярно, годами, что там немеряно всякого покруче опыта экспертности в ручной оптимизации помноженное на закон Мура.

а пока — спецы по ручной оптимизации — «сидят без работы»
а с работой — формошлепы и крудотворцы(у которых грид в админке умудряется листаться секунды, на каких-то 10 тыс записей. я и специально так бы не смог)

Скорость разработки решает.

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

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

он и просчитал
ему
— да как так так не выгодно, на рынке ж пусто!!!
— да так что
пусто сейчас, а через 5 лет кроме нас с тем же выйдут другие
и имя этим другим — Nvidia, с совсем другими как ресурсами, так и научными разработками
и наше — никому будет не нужно и даром.
мы УЖЕ опоздали с выходом на рынок, потому что наша разработка, подход УЖЕ не стала доминирующей, а у Nvidia — станет.

дело было что-то там в начале 2000ых

случайно я давно слежу за его судьбой, сейчас он благополучно техлидит в Бостоне, на TypeScript плюс React :)
то есть он вообще ушел, напрочь из этого направления. математик кстати, по образованию, МГУ, динамические системы, ...

так что, как в рекламе одной украинской турфирмы
«Выбирай сам», тебе чего, зарплат или тру программирования

Ну, я решил остаться, но жизнь для таких как я есть только на росте рынков.

да, кажется уже писал, проверял лично в 2008ом правило

в годы роста экономики — востребованы узкие специалисты, эксперты
в годы спада — универсалы, т.е. те кто «и швец и жнец и на дуде игрец»

кстати, узких формошлепов, как бы они там не постигли суть реакта, но которые в беке ни шиша — тоже поувольняют

а проверял тупо — по трендам на сайтах вакансий
на британском каком-то было супер очевидно

отношение вакансий по джава к php в 2007ом что-то 2:1
в 2009ом — 1:3

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

Оглянитесь вокруг: портативные компьютеры в тысячи раз мощнее тех, что привели человека на Луну. Тем не менее, каждый второй сайт не может обеспечить плавную прокрутку страницы на 60 FPS на последнем топовом MacBook Pro. Я могу комфортно играть в игры, смотреть видео 4K, но не прокручивать веб-страницы! Это нормально?

Почтовому приложению Google Inbox в браузере Chrome от той же Google, требуется 13 секунд, чтобы открыть письмо среднего размера:

This is, in real time, how long it takes for Google Inbox running in Google Browser to open an email. Not the shortest one, but still, it’s just text and pictures! Go Web Stack go!

Лагает не только на калькуляторах. Плевать не всем.
каждый второй сайт не может обеспечить плавную прокрутку страницы на 60 FPS на последнем топовом MacBook Pro

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

Плевать не всем.

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

швидкодія це така ж характеристика

то останнє про що буде просити користувач

швидкодія, оптимізації — то просто те чим люблять займатись програмісти.
а користувач чекає на вирішення своїх проблем — тобто функціональність, зручність, і не через 5 років. і не бажає переплачувати за те що йому не потрібно, або просто не має на те коштів.

на прикладі ковбаси, якось бачив сюжет, про фірмочку де роблять якісну, еко-,
кажуть — продавати складно:
вона виходить дороща в рази звичайної, невідомого з чого, з барвниками та підсилючами смаку
а на сліпих дегустаціях покупці обирають звичайну, бо вона — смачніша.

— чому ж не додаєете до своєї?
— тому що тоді на смак і вигляд вона буде такою ж самою. а різниця у ціні ще й збільшіться.

Але ж не всюди так

звісно що не всюди

софт для марсоходів аби як писати не можна.
шукайте вакансії у «NASA»

і взагалі, у ембедеді — в цілому не так.

«всюди» не існує. є світи програмного забезпечення.

В комп. іграх же ж турбуються про оптимізацію?

так. там турбуються. і я там, коли був, турбувався.

але теж, не дуже:
купи собі топову модель відеокарти — та й буде тобі fps
або — відключи оту «красотєнь»

тобто
маєш гроші — буде «оптимізація»
не маєш — не буде.

просто платити за неї будеш не розробникам гри.

Те що вебщики від безвиході змушені городити костилі для того щоб з купки DIV і інших тегів для оформлення тексту зліпити якесь GUI ніяк не відміняє того факту що призначення HTML і CSS це розмітка та оформлення тексту. Я впевнений що з таким самим успіхом web-переглядачі можна замінити на Excel і верстати анімовані слайдери і чати в xls файлах.

Алгоритм дії коли потрібно щось відцентрувати на сторінці:

  • Horizontally
    • Is it inline or inline-* elements (like text or links)?
    • Is it a block level element?
    • Is there more than one block level element?
  • Vertically
    • Is it inline or inline-* elements (like text or links)?
      • Is it a single line?
      • Is it multiple lines?
    • Is it a block-level element?
      • Do you know the height of the element?
      • Is the element of unknown height?
      • Do you care if the element stretches the height of the container?
      • Can you use flexbox?
  • Both Horizontally and Vertically
    • Is the element of fixed width and height?
    • Is the element of unknown width and height?
    • Can you use flexbox?
    • Can you use grid?
  • Conclusion
    • You can totally center things in CSS.
Centering in CSS: A Complete Guide
Як усі можуть бачити це дуже легко. Дуже ефективно.
Веб стак легкий для використання

Так можуть говорити ті хто нічого крім сайтів не робив. Як, наприклад, додати на сторіночку деревовидний список? В WPF, в Delphi та й в інших є компонент TreeView з документацією, з методами, все як треба. Ой. А в HTML такого немає. От біда. Ну нічого зараз накидаємо DIV’ів, списків, пару десятків рядків CSS і про JavaScript не забудемо для того щоб можна було згортати, розгортати вузли і от, воно нарешті готове. Звісно ж є jQuery, бібліотеки якісь з таким списком накостиляний не тобою, але тут починаються інші негаразди: переобтяжені сайтики зі складною версткою та різноманітними бібліотеками які вішають комп що тягне умовний Кризіс на ультрах. І от на одній шальці терезів в тебе уеб апплікасьйон представлений HTML сторінкою зі стрибаючими емоційками, картинками, деревовидним списком, полем для пошуку і декількоама формами а на іншій шальці Кризіс з симуляцією води правдоподібною фізикою та реалістичним вогнем. Веб апплікасьйон тормозить при прокручуванні сторінки і навантажує всі ядра ЦП, а Кризіс літає на ультрах.

Что Вы наделали? Теперь разработчики браузеров узнают о видеокартах, и без хорошей видухи на половину сайтов будет не попасть..

Вони і так в курсі про відеокарти і активно юзають їх можливості.

В WPF, в Delphi та й в інших є компонент TreeView з документацією, з методами, все як треба. Ой. А в HTML такого немає.

Зато такой компонент есть под любой популярный front-end framework. С документацией, методами и всем остальным. Чем это существенно отличается от WPF и Delphi?

В Windows, внезапно, TreeView тоже живёт в отдельной библиотеке Common Controls, это даже не часть user32.

По суті нічим. Це була ілюстрація того що HTML і CSS це для розмітки тексту і що вони погано підходять для UI. В WPF, Delphi всякі такі TreeView споживають менше ресурсів (впевен на 99%), мають більше можливостей, не зроблені на костилях і в цілому не такі колхозні.

споживають менше ресурсів (впевен на 99%)

Это сейчас никого не волнует.

мають більше можливостей

Серьёзно? Я вот ещё помню, сколько трахомудии нужно было, чтобы запилить ownerdraw в штатном виндовом TreeView.

И это... мы же помним, что ни WPF, ни Delphi не позволяют разработку кросс-платформенных desktop приложений (а именно о них речь)?

не зроблені на костилях

Опять же, никого не волнует, костыли там или нет. Если это выглядит как tree view и работает, как tree view — значит, задача с точки зрения бизнеса решена.

в цілому не такі колхозні.

Ну это бессмысленно комментировать, ибо вкусовщина.

Крузіс літає бо відеокарта допомагає розпаралелити ряд задач, якби це можна було б застосувати для HTML, це б давним давно вже зробили. Спробуй запустити будь-яку гру на процесорі (SwiftShader в допомогу) і побачиш як вона ледве повзає на мінімалках.

Алгоритм дії коли потрібно щось відцентрувати на сторінці

Лякатися центрування елементів у CSS якраз можуть тільки ті, хто нічого окрім сайтів, а то й їх, не робив. Все-таки блочну модель CSS зрозуміти набагато легше, аніж ковиляти Qt чи щось гірше. Більше того, якщо не підтримувати щось старе по типу IE, то флексбоксу достатньо для 99% кейсів. А уж він елементарний для сприйняття, якщо клепка є. Я вже мовчу що стилі то взагалі навіть не фронт-енд, а просто верстка, 1% айсберга.

призначення HTML і CSS це розмітка та оформлення тексту.

Аякже, а JS мова для запуску скриптів на сторінці. Знову ж, як там в 2002? Чули про теги svg, canvas, audio, video, айфрейм та інші? В сучасному вебі їх часто використовують. Для оформлення тексту, звісно ж.

Веб апплікасьйон тормозить при прокручуванні сторінки

Коли таки знавці як ви роблять сторінки на джиквері, звісно ж тормозить. Вони не чули про реактивне програмування, динамічну підгрузку, shadow dom...

Лякатися центрування елементів у CSS якраз можуть тільки ті, хто нічого окрім сайтів, а то й їх, не робив.

Web-програмісти роблять не тільки сайти?

Аякже, а JS мова для запуску скриптів на сторінці. Знову ж, як там в 2002? Чули про теги svg, canvas, audio, video, айфрейм та інші? В сучасному вебі їх часто використовують. Для оформлення тексту, звісно ж.

А що, JS не мова для запуску скриптів на сторінці? В web-перегяладчах більше не підтримується? Я впевнений що з таким самим успіхом web-переглядачі можна замінити на Excel і верстати анімовані слайдери і чати в xls файлах.

Коли таки знавці як ви роблять сторінки на джиквері, звісно ж тормозить. Вони не чули про реактивне програмування, динамічну підгрузку, shadow dom...

Discord, Skype та сайт Rozetka робили такі профі як я?

А для чого хвалитися тегами video, audio, iframe та іншими? І які це інші? Послухати і подивитися відео на HTML сторінці можна було вже давно і це вписується в концепцію інтерактивного документу? А що Canvas? Тетріс на ньому малювати?

Qt — это всё фигня. Можно писать интерфейс под DirectX/OpenGL, с трёхмерным интерфейсом в стеклянном стиле, вот это настоящий хардкор. А можно совместить это и с вебом, и пилить под css3D. Вот пример, чтоб иметь представления:
threejs.org/...​ples/#css3d_periodictable

blender так написан и это тоже создает проблемы потому, что на qt/gtk любой с++ разработчик сможет писать практически сразу, то directx/opengl/vulkan/metal имеют очень высокий порог вхождения. www.blender.org/...​rum/viewtopic.php?t=10192

по WCAG не пройде
свістульки написати вийде, але більшість інформаційних сайтів — нє

Я ж написав в чому проблема.

В первую очередь это касается энтерпрайза

я давно как называю свою сферу — в области разработки финансового экономического ПО
и писал и на GUI это ПО.

веб избавляет от кучи головняка.
никакого особого преимущества в скорости разработки у GUI нет.

а вот у веба — чем проще UI — тем быстрее его делать, чем на GUI

и только с сложными UI начинаются потребности в ангулярах с реактами. а до них в ExtJS

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

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

Скорость разработки и сапорта.
кроссполатформенность это уже для home users критична. в энтерпрайзе часто стандартизируют ПО, так что она не критична.

Скорость разработки и сапорта решает. Целиком, а не — «написал строчки кода = сделал». Это совсем еще не сделал, как то часто думают себе программисты. Это лаба или курсач еще, а не функционал продукта в эксплуатации.

Проще говоря, меня сильно удивляет то, насколько невостребованными становятся такие вещи как Qt, WPF и т.д.

WPF и прочие JSF в энтерпрайзе вполне встречаются.

но универсальные технологии — более масштабируемы, как по выбору гибкости решений, так и по выбору людей

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

а выберет то на чем умеет. иногда — хайповое :)

Потому что
Лучший инструмент — этот тот которым владеет команда
или
Серебрянная пуля, в которую верит команда, и на энтузиазме вполне может побороть ее сырость

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

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

Он требует — скорости разработки.

Скорость разработки и сапорта решает. Целиком, а не — «написал строчки кода = сделал». Это совсем еще не сделал, как то часто думают себе программисты.

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

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

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

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

это вообще о другом.

спросите заказчика, пиэмов и лидов — за что платят программисту.

Угу а еще спросить, быстро но могут проблемы с расширением поддержкой в будущем, или медленно, но все равно могут быть проблемы )

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

Вообще вопрос в сфере политики. Кто попу хуже лижет, того и сократят раньше.. Кто дороже обходится, того и сократят раньше.

можете и погуглить мнения лидов о разнице между джун-мидл-синьор.

Сколько людей, столько мнений.. Для себя вынес, чем больше тебе платят, тем ты лучше. А лычки просто способ манипуляции.

Угу а еще спросить, быстро но могут проблемы с расширением поддержкой в будущем, или медленно, но все равно могут быть проблемы )

ну не спрашивайте конечно, если знаете заранее ответы :)

Кто дороже обходится, того и сократят раньше.

и такой критерий бывает

Для себя вынес, чем больше тебе платят, тем ты лучше.

ну так речь же не о том как вы себя оцениваете.
а как вас оценивают.

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

Вообще вопрос в сфере политики

конечно. а где ж ему быть когда — peopleware

да это как бы понятно что программист, любой, до тех пор программист пока работает с кодом.

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

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

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

не часто видел, что бы сказали пиши в 2 раза дольше, что бы потом лучше сапортилось..

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

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

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

и в этом случае тоже, зависит от конкретной компании, команды, что будет происходить дальше с такой таской, и какова будет реакция на второго программиста
но в общем случае оценка будет — да нафик кому нужен твой код! просто не скажут, это ж демотивирует :)

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

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

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

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

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

а третьей команде — вообще просто повезло оказаться в нужное время в нужном месте спроса
копируйте!

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

Хорошему программисту тоже не скажут пиши в 2 раза дольше, но что бы лучше сапортилось.. Или найдется еще более лучший? А сколько раз можно повторить? А тот программист, что напишет хороший код в 2 раза быстрее стоит столько же, сколько и тот, что пишет в 2 раза дольше? А в разрезе нескольких лет, хороший будет всегда писать в 2 раза быстрее?
Я вообще не понимаю, зачем тащить в вопрос разную компетенцию. Если вопрос был о одном среднем программисте, без привязки к компетенции.
Моя основная мысль была, программист может отвечать за результат только в тех узких рамках, что ему назначили заказчик, ПМ, аналитик, тимлид, и т.д.
А то сначала, напиши на языке Х, фрейморке У за время Й, а потом — что за «х» «у» «й» получился?

Хорошему программисту тоже не скажут пиши в 2 раза дольше

да, не хватало еще чтобы хорошему нужно было такое говорить
какой же он хороший тогда

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

А тот программист, что напишет хороший код в 2 раза быстрее стоит столько же, сколько и тот, что пишет в 2 раза дольше?

нет, разница в оплате редко будет значительной :)
по многим причинам, долго объяснять, и 150% холивар будет. неинтересно.

А в разрезе нескольких лет, хороший будет всегда писать в 2 раза быстрее?

ценнее — будет. будет ли быстрее — в среднем за период будет получаться и быстрее.

Если вопрос был о одном среднем программисте, без привязки к компетенции.

тогда какой критерий усреднения?

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

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

А то сначала, напиши на языке Х, фрейморке У за время Й, а потом — что за «х» «у» «й» получился?

ну вот, по «х» «у» «й» получился и оценивают. и делают вывод, сложная для него оказалась задача. давайте найдем ему попроще. — а нет уже простых!
ну, давайте искать ему замену тогда. или учить, или ... — разные бывают

конечно, нередко записывают и в фейл лида — ты почему этому тупню дал эту задачу? ты почему не знал что он ее зафейлит? твой фейл!

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

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

тогда какой критерий усреднения?

Software Engineer за 2,2к$ Медиана по доу для Украины, если что..

почему тупней не увольняют сразу, как поняли, что они тупни?

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

вобщем незачем спешить, с увольнением. вот и не спешат.

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

как наймут — так и вполне уволят.
а может и оставят, пусть тупит, пока есть польза.

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

Software Engineer за 2,2к$

в какой области разработки?

как я уже писал — оплата зависит от области, и к механике разработки ПО о которой рассказываю не имеет отношения. это конечно не вся механика.

вы выбрали себе критерий, ну и ладно. ваша карьера, ваша жизнь — выбирайте сами.

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

основные черты для группирования критериев назвал вроде.

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

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

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

Я бы основной проблемой выдел то, что часто команды выбирают хайповую технологию, в которой не имеют достаточного опыта,

если им дадут — лиды.

Результат — срыв сроков на проекте, превышение бюджетов и т.д.

технологические причины срыва сроков, превышения бюджетов — ни в какое сравнение не идут с другими.

Но девелоперы далеко не всегда понимают, что бизнесу надо решить задачу с помощью наименьших затрат

на самом деле, если опытные, то понимают
просто — «жизнь одна», и фиксать легаси — психологически тяжко.

если им дадут — лиды.

А лиды тоже меж двух огней. С одной стороны, то самое соблюдение баланса «стоимость/качество/не сломать ничего уже работающего», с другой — сложность набора людей в команду, если предполагаются скучные проверенные временем технологии.

А лиды тоже меж двух огней.

да.
вообще все меж двух огней, кого не возьми.
без сарказма.

100%. Только хотел то же самое написать. Девелоры проталкивают и ведутся на хайп ради баззворда в резюме. Менеджеры чаще всего против новых технологий: работает — не трогай.

Девелоры проталкивают и ведутся на хайп ради баззворда в резюме. Менеджеры чаще всего против новых технологий: работает — не трогай.

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

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

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

Техлиды и архитекторы такие же заинтересованные люди, которым нужно апдейтить резюме новыми словами.
Даже если есть дев менеджер из бывших девелоперов, он может запросто повестись на моду (был кейс).
Тех. человек для принятия таких решений — это правильно, но он должен быть полностью рациональным, что не так часто как хотелось бы. Чтобы и девелоперы от скуки не разбежались и продукт не рухнул от мишуры.

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

конечно
все такие же заинтересованные люди в своей карьере, жизни, и т.д.

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

да, может. и даже может будет прав.

это правильно, но он должен быть полностью рациональным, что не так часто как хотелось бы.

в действительности он может быть и иррациональным. опыт то обычно превращается в интуицию.
и делать то не ему, а команде :)
то есть тут надо картинку вставлять boss vs leader

главное что — нет такого человека. или группы людей — ух дорогой, долгий, мучительный получится проект. для всех, и для пиэмов, и для программистов

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

2. вам надо найти или выделить — человека, группу с тех бекграундом, который/-ые может и хочет взять на себя согласование проекта. хоть архитектором его назовите, хоть принципиального инженера лычки им раздайте. без этого, все туфта, мероприятия, метрики, премирования и скрамо-аджайлы.

этот работает

насколько невостребованными становятся такие вещи как Qt

эээ.. корпоративные распределенные решения это не только десктоы на винде

> тому що є той же Qt і Java яка один раз написана і запускається скрізь
Только если писать какой-нибудь калькулятор, не вылазящий из своей песочницы. Если же попытаться хоть как-то повзаимодействовать с системой, то начинаются приколы, от разных форматов адресов файлов до платформ-специфичных глюков рантайма.

Каким образом электрон решает эту проблему?

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

Высокоуровневое

Qt API

практически под любую
задачу

Топящие за Qt лучше бы сделали под него биндинги под тот же C# (GTK смогли же), ну или, хотя бы, Dart. Пока эти API будут доступны только из C++ и, с кучей оговорок, Python — Qt останется нишевым решением для тех, кто умеет в «плюсы».

Ребята из NodeGUI хотя бы попытались, и то «труЪ» Qt фанбои сразу же набросились — фу-фу-фу, нет акселерации.

Топящие за Qt лучше бы сделали под него биндинги под тот же C#

зачем?

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

Иначе — будет съеден Electron + в ближайшей перспективе Flutter.

Ніяким Electron воно зʼєдене не буде. Далеко не всі програми це HTML сторінки поміщені в огризок Хромога.

Далеко не всі програми це HTML сторінки поміщені в огризок Хромога.

А я не зря сказал:

всё больше будет вытесняться в область нишевых решений

Да — там, где нужен прямой доступ к оборудованию или низкоуровневым функциям ОС, или интенсивная работа с графикой за пределами возможностей Canvas / WebGL, или обработка аудио/видео — без старой доброй десктоп разработки никуда.

С остальным HTML5 + JavaScript + Chromium + NodeJS (да, не нужно забывать, что в том же Электроне не только браузер, но и Нода с возможностью доступа к целому ряду системных API) — справляется более чем успешно.

Вебщиики атакують. Голактеко опасносте. З вебного в мене тільки Skype (вимушено).

А потому что без этого он мало кому интересен

кстати, знакомые финны тут ищут на ремоут Qt4/QGraphicsView/QWidgets. кому интересно — в личку

flatpack, staticlink etc etc

Первое нафиг не нужно.

Запахло бородатым линуксоидом образца начала-середины 2000х. Flatpak поддерживается кучей дистрибутивов, уже довольно много популярного софта через него распространяется, но да — «нафиг не нужно».

Лучше куковать и ждать, пока мэйнтейнеры соизволят добавить новую версию нужного тебе софта в официальный репозиторий — это философия труЪ линуксоидов? )))

а иначе твой софт просто гемор и требует твоего постоянного саппорта и не только в фиксинге багов.
Для проприетарного под 1-3 заказчиков это нормально

Inkscape, Spotify, Blender, PyCharm (и прочее от JetBrains), LibreOffice, GIMP — конечно, все они идиоты, раз публикуют свои приложения в Flatpack, один Виктор умный

Нет, это все через Flatpak распространяется

LibreOffice я запросто через синаптик сношу, какой-то неправильный у них флатпак

Ну так бОльшую часть из списка, естественно, можно и синаптиком поставить. Вопрос в том, какой свежести будет версия в репозитории синаптика.

Ну и лично у меня был опыт с Manjaro Linux, когда или трахайся с AUR (очередное приехавшее из AUR обновление прибило системную библиотеку libc, после чего естественно система при загрузке начала падать в kernel panic), или ставь как белый человек из Flatpak как из любого маркета приложений.

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

Справедливо. Но на манжаре почему-то свежие версии Хрома только через AUR...

есть chromium в пакмане, «все работает» ©

Chromium и Chrome — всё-таки, немного разные вещи, не?

Да, собственно, потому же, почему сейчас даже сайты-визитки выжирают по 500МБ оперативы:
Потому что пипл хавает, и добавки просит! Вот если б типичный пользователь возмущался этим показателем, расклад сил был бы совсем иной. Но что вы хотите от среднестатистического пользователя, когда даже программистам в большинстве своем, пофигу, сколько ресурсов потребляет та или иная веб-страница, лишь бы она решала поставленную задачу?

От якби типовий громадянин відстоював свої права, от якби типовому програмістові... Піпл не просить добавки у вигляді ще однієї тормозної сторіночки напханої JavaScript і CSS, а хаває те що є, те що дають. Ну і обурюються деякі. Наприклад я. В даній ситуації апеляція до якогось там звичайного користувача це просто перекладання відповідальності особливо враховуючи компетенцію звичайного користувача.

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

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

А что могут сделать веб-программисты? Собраться в проф. союз и заявить «мы не будем делать говно»? Так наймут тех, кто будет. Оно примерно так сейчас и происходит: хорошие спецы стоят дорого, и заказчик не видит смысла за них платить, когда недоученные студенты выкатят какой-никакой результат за куда меньшие деньги, по методологии «тяп-ляп — и в продакшен».

А что могут сделать веб-программисты? Собраться в проф. союз и заявить «мы не будем делать говно»?

Щось таке.

Да, приходится с сожалением согласиться что Electron победил. Для бизнеса главное сделать быстро и дешево, на чем — не важно. От того и имеем, что какой-нибудь чатик, просто для обмена текстовыми сообщениями отжирает в немеряных количествах память. С другой стороны, если посмотреть что на сегодня есть для кроссплатформенной UI разработки, то окажется что особо-то ничего и нет. Qt, WxWidgets = C++ спецы будут стоит дороже. Для себя использую Lazarus, умеет компилить в нативные контролы ОС (windows) или Qt, GTK (правда, 2й версии, 3я только в альфе) под linux, bsd и всё равно есть заморочки, когда одно и тоже приложение выглядит и работает в разных системах. Тут еще говорили про Delphi, да можно использовать Community версию, но привязка идет только к Windows, для коммерческой разработки нужно покупать лицензию, что для pet проектов избыточно. Да, и еще можно использовать Tcl/Tk, но популярных приложений на нем не видел, если не считать gitk, git gui.

что на сегодня есть для кроссплатформенной UI разработки, то окажется что особо-то ничего и нет.

JavaFX. 100% кроссплатформенная, уже даже вендор-независимая. Возможности очень широкие.

И спецов, умеющих именно в JavaFX, ненамного больше, чем на C++ (плюс попробуй ещё уговори современного джависта писать под десктоп)

И спецов, умеющих именно в JavaFX

у меня один давний приятель, джавист, делал небольшой проект JavaFX.
сделал, сдал, оплату получил, клиент доволен.
но сказал в итоге — больше никогда!

Почему?
Я работал с JavaFX, правда для себя. Вполне приятный фреймворк, логичное апи, нет никакой дичи.

это было года 3 тому.
1. баги. но думаю что стало лучше конечно.
2. нехватка функционала и сложность его реализации для реализации хотелок заказчика

правда для себя.

может в этом дело. он делал реальный проект

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

Однозначно можно только сказать что JavaFX не взлетел. Почему, да, вопросы.

Однозначно можно только сказать что JavaFX не взлетел

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

А у вас он однозначно не взлетел, ну да :)

взлетел — понятие относительное.

как я недавно смотрел индид — вакансий и на Java Swing есть.

На JavaFX создают кучу десктопного софта

взлетел/не взлетел — это сопоставление размера куч.

Да вроде как javaFX просто еще один фреймворк.. Чего его выделять отдельно. В java вообще меньше разработчиков одного фрейморка, по сравнению с другими языками. Потому в вакансиях на отдельного javaFX разработчика нет смысла..

Да вроде как javaFX просто еще один фреймворк

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

Как минимум, например, все компоненты JavaFX изолированы от внешнего мира запретом вызывать их вне главного треда JavaFX Application Thread. Только этот тред может вызывать компоненты юая. Взаимодействие с другими потоками в приложении возможно или через абстракции типа очередей, например, или через асинхронные задачи самой платформы. Что в целом логично, но для «я у мамы веб-программист» это слооожнаааа.

взлетел — понятие относительное.

Все продукты жидбрейнса написаны на JavaFX.
Учитывая, что та или иная идешка стоит почти у каждого, то это взлетел.

Все продукты жидбрейнса написаны на JavaFX

не знал, удивился, я то думал...

пошел в intellij-community/platform/core-ui/src/ui/
а там, как мне и помнилось:

import javax.swing.*;
import java.awt.*;

из того что я знаю об JavaFX, был как-то на докладе на его старте
у него ж декларативный подход?

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

все компоненты JavaFX изолированы от внешнего мира запретом вызывать их вне главного треда JavaFX Application Thread.

на Swing так же

да и вообще везде в зрелых GUI фреймворках

не знал, удивился, я то думал...

Да. Ни свинг, ни тем более авт не позволят нарисовать их идею даже близко, а вот фх — да.

а там, как мне и помнилось:

Некоторые, очень редкие классы JavaFX имеют API-порты для свинга.

import java.awt.*;

Уверен, что это или какие-то общие енумы, или java.awt.Desktop.
java.awt содержит не только гуй.

из того что я знаю об JavaFX, был как-то на докладе на его старте
у него ж декларативный подход?

Хз что в данном случае имеется в виду под императивный/декларативный

на Swing так же

Нет

Ни свинг, ни тем более авт не позволят нарисовать их идею даже близко, а вот фх — да.

могут. просто на уровень ниже свинга нужно опуститься
но, в данном случае — буду знать. посмотрю, если будет время-желание

P.S.
User Interface Components

The IntelliJ Platform includes a large number of custom Swing components. Using those components in your plugins will ensure that your plugin looks and works consistently with the UI of the rest of the IDE, and can often reduce the code size compared to using the default Swing components.

www.jetbrains.org/...​interface_components.html

теоретически, они конечно могли переписать самый нижний слой Swing’а...
но если они туда спустились, то и незачем, и проще добавить в средства рендеринга свои фичи

на Swing так же
Нет

что нет :)

не, конечно можно для простого примера дергать Swing компоненты из любого потока.
Но быстро вспомнится что тебе ж говорили:
SwingUtilities.invokeLater() is great for updating the UI from another thread.
и про SwingWorker

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

Хз что в данном случае имеется в виду под императивный/декларативный

Add the following two elements between the opening and closing
<GridPane> tags in the file sample.fxml: <Button text="Say 'Hello World'" onAction="#sayHelloWorld"/> <Label GridPane.rowIndex="1" fx:id="helloWorld"/>

это и есть — декларативный

конечно можно для простого примера дергать Swing компоненты из любого потока.

вот именно, что в свинге можно. А в ФХ — нельзя. При попытке вызова юайных апи не из юайного потока, получите эксепшн.
Т.е. они сделали принудительное разделение слоев и логики на уровне архитектуры. Юай отдельно, логика отдельно, между ними асинхронные штуки разные.

они сделали принудительное разделение слоев и логики на уровне архитектуры.

думаю что это вынуждено получилось. аппаратный рендеринг потребовал жесткого выноса

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

на свинге тоже, довольно быстро получишь. как только появятся потоки в приложении.
хотя и «можно» :)

так что в main инициализация и старт «сами оборачиваются» в
SwingUtilities.invokeAndWait

Ни свинг, ни тем более авт не позволят нарисовать их идею даже близко, а вот фх — да.

не нашел, сдаюсь

стянул исходники, кругом работа с наследниками JComponent, в Swingовом стиле

в доке по платформе тоже не упоминается

даже тупо
по всем файлам java
javafx.

только плагин для создания FX приложения, да лончер для запуска разрабатываемого приложения, у которого
  private static boolean startJavaFXApplication(String[] params, Class appClass) {     try {       //check in launch method for application class in the stack trace leads to this hack here       Class[] types = {appClass.getClass(), params.getClass()};       Method launchApplication = Class.forName("com.sun.javafx.application.LauncherImpl").getMethod("launchApplication", types);

и кругом в коде
и ApplicationManager.getApplication().invokeLater(() ->
да ... ModalityState
то что и в доке у них написано:

invokeLater

To pass control from a background thread to the event dispatch thread, instead of the standard SwingUtilities.invokeLater(), plugins should use ApplicationManager.getApplication().invokeLater().
www.jetbrains.org/...​eral_threading_rules.html

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

то есть поток UI у них получается — тоже Swingовый.

делитесь инфой, откуда узнали

Все продукты жидбрейнса написаны на JavaFX.

... а Eclipse увалился с StackOverflow, при создании проекта.
дал ему 8М на стек, и ок.

Да, сейчас погуглил и признаю, что скорее всего ошибался насчет идеи.

Удивительно что никто не написал об истинной причине — одна кодовая база с web версией продукта. Поэтому и используют.

Скоро будет лучше, потому что Chromium движок будет встроен в Windows (через новый Edge и уже не нужно будет качать большой инсталлер)

одна кодовая база с web версией продукта.

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

но более общий фактор все же — опыт создания Web UI у программистов
переучивание с JS на «C#/Java», с HTML-CSS на «WinForms», «Swing» — на классические яп и фреймворки для GUI — будет не быстрым

И главная причина — HTML-CSS — воспитывает декларативный стиль мышления программиста
а классические подходы к GUI это императивный, ООПшный.
там много еще отличий, у вебщины в мозгу и «тру» программирования, там же, в мозгу программиста.
которые хорошо видны когда фронтендер переходит к бекенд разработке чего-нить серьейзней чем serverless.

Про кодовую базу — это да, но Chromium из коробки в Windows вряд ли как-то протолкнет электрон. Скорее, наоборот: меньше будет причин переносить сервис из веба в приложение.

Edge O_o.
Он на хромиуме.
И скоро им заменят старый Edge.

А я о чем? Зачем нужен электрон, когда все и в браузере неплохо работает?

Мы о разном.
Я о Електроне на движке встроенного в систему, как аналог ActiveX.
То есть приложение будет упаковано в интерфейс, обновляться и тд, но не будет тянуть движок.
Когда MS впилил Chakra, то были форки електрона как раз нацеленные на такую реализацию.

В браузере всё несколько грустно с доступом, как минимум, к локальной файловой системе и десктопу (тот же system tray), запуском дочерних процессов, декодированию аудио / видеопотока помимо штатных возможностей самого браузера.

Тот же Скайп, вопреки распространённому заблуждению, не полностью написан на Электроне. На Электроне там только UI, а сам движок видеозвонков, например, сделан нативным расширением, как и сетевой протокол взаимодействия с серверами, скорее всего.

Скайп так реализован не потому что сделать все на electron было невозможно, а потому что пришлось тянуть совместимость с текущей инфраструктурой, да и кодовая база вся нативная. Есть Hangouts, есть Discord, которые работают без нативных расширений.

Есть Hangouts, есть Discord, которые работают без нативных расширений.

расскажите, на чем написан тот же WebRTC?

WebRTC — часть платформы (в данном случае — браузера), предоставляемая как API.

повторю вопрос:

на чем написан тот же WebRTC?

и почему?
почему не на жабоскрипте как предлагает Виктор?

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

Это примерно то же самое, что спрашивать, на чём драйвера устройств написаны. Да хоть в машинных кодах — прикладному разработчику важно, чтобы ему предоставлялся высокоуровневый API для работы с устройством / кодеком / видеопотоком. А что там и как под капотом — это забота рантайма.

Если ты намекаешь на то, что системный софт и сам рантайм нельзя написать на JavaScript — так я никогда и не утверждал обратного. Хотя, с появлением той же Webassembly всё большая часть не критичного по времени исполнения до единиц миллисекунд кода будет переписываться и на JS в том числе.

Манічка все всюди пихати JavaScript.

Серверні програми які могли бути написані на якій-небудь Java вирішили написати на модному JavaScript.

Тому що виявилося що простіше, чим на якій-небудь Java

Бо чим далі, тим менш є потреба писати свій сервісний функціонал — він вже написаний, і або став собі його на сервер, або підключайся до нього.
І написати треба тільки свою, унікальну бізнес логіку, та glue, міжсервісний код.
І виявляється, що така система буде чималу частину часу просто чекати відповіді від сервісів. А для того щоб вона обробляла багато запитів, ..., ...,

то навіщо для цього Java, якщо на JS/TS те швидше пишеться, а асінхронність Node.js у таких сценаріях краща за треди?

А є ще і PHP, який теж не трушний...
Java will kill your startup. PHP will save it.
medium.com/...​will-save-it-f3051968145d

If you focus on tools ahead of architecture, you may end up pounding nails with a battering ram (Java) when a hammer (PHP) would have been both sufficient and appropriate. You will also quickly lose money investing in tools and staff that aren’t necessary. If you want to build a skyscraper, then design a skyscraper. Strong enterprise solutions are built with good architecture and design, not with a specific language.

це ж стосується і вибору Ноди замість якій-небудь Java

колись я запитав свого першого ментора
— а то правда що справжні програмісти пишуть на C (бо ж я писав на С) а не на Basic?
відповідь здивувала, бо й він писав на С
— справжньому програмісту в загальному випадку байдуже на чому писати. все одно вийде в нього — добре.

Всё правильно написано, но onemore бесполезно объяснять — он либо тролль, либо реально фанатичный «старовер».

як він витіснить решту тулзів

Так это факт реальности. И Джефф Этвуд, отец-основатель StackOverflow, говорил об этом ещё в далёком 2007м, когда JavaScript ещё и близко не был хайпом:

blog.codinghorror.com/...​principle-of-least-power

I’ll call Atwood’s Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
Если программист считает, что асинхронность сделает его код быстрее, то либо он профессионал, который занимается очень специфичными алгоритмами, либо он не совсем понимает о чем речь. Или же он сторонник формальной правоты в ущерб здравому смыслу. В вебе, особенно в некрупных и средних проектах параллелить особо нечего, да и в крупных уже прижилось хитрое кэширование для тяжелых запросов или кусков контента. Ну и треды там всякие...

Javascript: фрактал отсоса

PayPal and Wal-Mart have also had high-profile switches to Node.js. Of course, they’re comparing two completely different things to make Node.js look better. In these too-good-to-be-true stories, they’re switching from a gigantic enterprisey codebase to a Node.js app written from scratch. Is there any question that it wouldn’t have been faster? They could have switched to pretty much any anything and gotten a performance gain.

The emperor’s new clothes were built with Node.js

Javascript: фрактал отсоса

13 марта 2014
и там он еще Когда-то давно мне попалась статья про недостатки PHP. та нашумевшая статья от 16 апреля 2012 «PHP: фрактал плохого дизайна»

The emperor’s new clothes were built with Node.js

4 June 2014

и конечно не все с тех пор исправлено, и т.п.

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

так все таки, я не понял, о чем топик

Пластмасовий мір побєділ?

или это просто галюцинации у топикастера, а вебщина вместе с вебщиками доживают последние дни?

PHP уже умер, это факт.
ждем похорон JS, потому есть мнения какой он узасный?

есть правда и мнения что он уникальный сплав LISP+Smalltalk, но это ж надо отложить хейтинг, вникать в историю развития ЯП, концепций, то есть — философию программирования.
а «тру технарь» об такое мараться не будет конечно.
теме более когда он уже выбрал Самый Правильный Язык Программирования.

Не догматизм, а геніальне ессе, монументальна праця.

Вопреки мнению о том, что программисты — не люди, множеству людей из среды программистов также свойственно объединяться вокруг доминирующих в обществе идей. Ибо, во-первых, могут не понять и растоптать, а во-вторых, можно не понимать и топтать других. За третьим и четвертым номером следует причастность к великому и чувство локтя. Но во время дискуссий, как правило, всплывает только второй пункт. И все эти толпы программистов, пишущих на Javascript(кроме вас, конечно, дорогой читатель), будут готовы возвести вас в сан елейного дегенерата за то, что вы не разделяете их восторга перед переименованными технологиями 30-летней давности.
А огромное количество людей, помноженное на низкую квалификацию и чудовищный спрос, рождает высокую необъективную самооценку, воинствующее невежество, илитизм по линии фронтенд-бэкенд.
Не догматизм, а геніальне ессе, монументальна праця.

прочел. там минимум треть — как раз то что вы процитировали.
буйство чувств и эмоций :)

собственно программерские форумы часто и выполняют эту функцию. поэтому хейтерство — обычное дело.

ждем WebAssembly

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

ждем, свободного выбора.

но JS все равно ж останется, весьма нетипичным ЯП среди мейнстримовых.

PHP ще довго не зникне. А у часи економічного спаду ще й більш нових проектів на ньому буде.

Але про нього у відповідній хейтерській темі. Як буде, і буде такою ж цікавою

Так есть же куча транспиляторов для JS. Даже со Scala, для эстетов :)

Есть функциональные Elm и ReasonML.

Есть похожий на Java/C# TypeScript.

Но «ёжики плакали, кололись....»

Я последний проект на Typescript делал чисто в функциональном стиле с помощью fp-ts.

Но классы и интерфейсы да, там есть и весьма похожи на шарповые. И даже discriminated unions есть.

Однозначно лучше с типами. А особенно, когда в ход начинают идти монады — по крайней мере, в fp-ts без типизированных дженериков было бы крайне сложно.

Мені байдуже до js. А з телепатами психотерапевтами якось вже нудно навіть тролитися

По первой цитате даже комментировать не хочется. Если её автор сам не понимает разницы между асинхронностью и параллелизмом вычислений — то ему самому впору садиться за учебники.

По второй там тоже автор местами подтасовывает карты — в Javascript давно завезли async / await, а автор до сих пугает ужасами callback hell.

И, затем — мы тут вроде бы обсуждали desktop GUI, в то время как вторая статья вообще про бэкенд разработку. Но, если уж говорить о back-end, то, бесспорно, есть языки и рантаймы, которым NodeJS в определённых условиях проигрывает. Только вот таких граничных случаев, которые бы объективно оправдывали использование именно Java или Golan — не так и много. А в остальных случаях NodeJS вчистую выигрывает у тех же Python или Ruby скоростью работы, а у Java — гораздо большей легковесностью инструментария, динамичностью и гибкостью языка (если мы про ES2015).

Це вже плюс?

Конечно, плюс. А то на той же Java с её минимумом синтаксического сахара приходится заниматься «збоченнями» совсем другого рода — Lombok и прочие annotation processors.

Як часто потрібна швидкість роботи більша за пітон

Всегда, когда нет лишней кучи денег на дополнительные сервера.

Ось PHP теж швидший

«Чем армяне?» © КВН :)

У маня мірку жс фанатиків.

А давай мы не будем опускаться до культурного уровня трамвайных хамов?

Відкрийте Доу вакансії і подивіться кількість вакансій для ноде жс. Зливає всім бекенд мовам.

Для меня более объективным показателем является то, на чём заказчики хотят делать проекты. А там NodeJS в лидерах, особенно в стартапах.

У Python / PHP, правда, сильные козыри в виде Django / Laravel, и если нужно сделать «типичную админку», то они будут лучшим выбором по стоимости разработки.

Ну и Java сохраняет позиции в больших enterprise проектах.

Что до вакансий, то вначале нужно бы отфильтровать те, где ищут людей на поддержку написанного несколько лет назад.

Пруфов, как всегда, не будет?

методика Tiobe показує кількість балачок про мову, а не її використання.

і майже нічого не надає для прогнозів про майбутнє мови.

Маєте краще — викладайте

статистика що не відповадіє дійсності — не повина враховуватись взагалі. або треба точно вказувати що вона відображає

наприклад, як так може бути, коли щось там 80% сайтів зроблено на PHP, і точно викорстувається JS — а Tiobe показує які місця?

Порівняйте рейтинг Tiobe наприклад з
www.zdnet.com/...​-now-outnumber-java-ones

а ось ще така статистика
Here are the Top 7 programming languages with most job posting on Indeed as of January 2019:
Java — 65,986 jobs
Python — 61,818 jobs
Javascript — 38,018 jobs
C++ — 36,798 jobs
C# — 27,521 jobs
PHP — 16,890 jobs
PERL — 13, 727 jobs

www.codingdojo.com/...​ramming-languages-of-2019

То кому довірити більше з трьох
Tiobe, SlashData чи Indeed

як на вашу думку?

не розказуйте про ріст джаваскрипту.

тобто ви натякаєте що автор
Чому збочення на Electron стали нормою?
неадекват?

як і всі ті що волають в цій темі про цю маргинальну — норму?
це як, норма і маргінальна водночас?

От в 2017 році був джаваскриптовий хайп, так. Тепер нема вже,

а подивіться уважно на картинку, en.wikipedia.org/wiki/Hype_cycle

там є така штука, після хайпу як
Plateau of Productivity

любий хайп — то перебільшення, завищенні очікування.

і от якраз те що — після хайпу, і є показником.

І казки про те який реакт нейтив сілвер булет теж розчинилися в реальності.

про світ мобайла не скажу, не слідкую там за трендами :)

але казкам Tiobe давно не вірю.
як і графікам без розуміння того яки явища вони відображають, і розуміння суті тих явищ

на прикаді Tiobe
якщо не розуміти де зазвичай викорстовується Java, C, JavaScript — то припущення про їх майбутьні місця там будуть просто гаданням
а бажано і причини з’ясовувати... чому так склалося на зараз, та що з тих причин — змінюється, чому, який опір і чому буде чинити «інерція» тим змінам, і т.і.

просто тицьнути «у Tiobe» — то ні про що
як і у любу іншу статистику

Не все програмування — веб формошльопство?

а хто казав про — все?

Кофіскріпт? Серйозно?

а ви серйозно вважаєте що вас хтось зобов’язаний переконувати? ;)

ви просили, я вам надав, що не Tiobe єдиний у світі. у гуглі ще повно інших стат данних, за іншими методиками, з інших джерел, ...
більш адекватних до реалій.

Я висловлюю не свою думку, а приводжу статистичні дані.

тобто дієте за правилом
Існує три види брехні: брехня, нахабна брехня й статистика

думати ризиково, так. краще сховатись за «статистикою»

Я до цього сам дійшов

а щоб загуглити ще такє
Most In-Demand Programming Languages for 2020
та подивитись на тренди на поради
не дійшли...
а так, може б замислились, чому ж так...

Я і не писав що тіобе відображає 100% правду.

він відображає балаканину, увагу.
а ніяк не причини.

я вам про це написав. а не про правду.

WebRTC — часть платформы (в данном случае — браузера), предоставляемая как API.
Я эксперт по чему угодно, дайте либу — любой софт напишу! Нет либы — все, пиши пропало. Либы для чего угодно писать я не могу.

Ещё в незапамятные времена программисты делились на «системщиков» и «прикладников». Потом, на какой-то период, разница несколько стёрлась, так как даже для написания прикладного софта на PC довольно долго нужно было хорошо понимать, что и как работает «под капотом» и уметь общаться с операционной системой на языке довольно низкоуровневых API.

Но такая ситуация не очень устраивала бизнес, и, как грибы, пошли расти RAD инструменты: Delphi, Visual Basic, дотнет с его Winforms и затем WPF. Ну а теперь, когда MacOS прочно укрепилась на рынке десктопа, да и Линукс медленно, но уверенно отвоёвывает жизненное пространство — появилась потребность в кросс-платформенных RAD инструментах.

А что там было до Электрона? Qt / WxWidgets — требует дорогих специалистов, Delphi мало того, что стоит конских денег, так ещё и растерял большинство приверженцев. Mozilla со своим XUL как-то быстро сдулась, да и по сути их подход не сильно отличается от Электрона. JavaFX ещё — но, по рассказам пробовавших, хорошую, в общем-то, задумку, так и не довели до ума.

Вот и имеем то, что имеем.

Не були, а є. XUL мабуть трохи випередила час тому що тоді весь цей JavaScript був не таким модним.

Не були, а є

Qt ещё шевелится благодаря специализированному десктоп софту.

Остальное — да, формально до сих существует, но в реальности используют эти инструменты разве что малочисленные энтузиасты.

Eclipse существует весьма не формально, и в качестве кроссплатформенной и свободной IDE используется весьма широко отнюдь не малочисленными энтузиастами.

Так про Eclipse и речи не было. Разговор был про Qt, JavaFX, WxWidgets и XUL, и про то, что, за исключением разве что Qt в некоторых нишах, всё это сейчас вытесняется Электроном.

Qt ещё шевелится благодаря специализированному десктоп софту.

нит

Аргументы будут? Или очередные безапелляционные заявления?

embedded: automotive, health industry etc etc

Ну про embedded никто и не спорит, хотя в том же automotive Android ощутимо наступает на пятки. Речь же про десктоп была.

Ведроид и автомотив — ну разве что простенький аудио проигрыватель с доступом к машине только в варианте получения питания от нее.

А Qt, думаешь, где в automotive используют? Примерно там же — в мультимедийных системах и прочих пользовательских интерфейсах на передней панели.

В браузере всё несколько грустно с доступом, как минимум, к локальной файловой системе и десктопу (тот же system tray), запуском дочерних процессов, декодированию аудио / видеопотока помимо штатных возможностей самого браузера.

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

Но ругают-то именно браузерный GUI

так системщики с прикладниками давно холиварят

чье программированиее важней и трушней?

цена вопроса ж — самоуважение.

поэтому говнометание с хейтингом не до первой крови, а до смертоубийства :)

Мені тут спало на думку що навіщо Electron потрібен якщо можна просто зберегти сторінку в файл?

Хайп может и прошел, а вот популярность и близко не падает, но многие как в той картинке за ручку держат JS, а взгляд уже устремлен на TS.

TS — це коли уже омивають тіло перед похованням.

Если Flutter выстрелит для десктопа, то у него есть все шансы хорошенько потеснить Electron.

По поводу Blazor пока смутные сомнения — он ориентирован на дотнетчиков, и собирается в WebAssembly, которой нужен браузер со всеми вытекающими недостатками в виде потребления памяти и размера дистрибутива (если мы говорим о десктопе).

Blazor лол і страшний інтерфейс. Також без візуал студії (не код) нічого не зробиш. Демки блазора під веб це взагалі навіть не смішно.

Flutter це майбутнє, а де-куди і сьогодення, розробки під усе: iOS/Android, Windows/macOS/Linux, Web.

Я на флатері з однієї код бази збираю білди під всі мажорні платформи (під лінукс впадло, все одно ніяка платформа):

github.com/...​mdim/locadeserta/releases

web: locadeserta.com/sloboda

О, а поддержку Windows и Maс уже завезли? Круто!

так, в мастері є + треба невмержену одну офіційну репу юзать. а так все працює :)

реакт це труп. Краще освоїти uni-directional-flow + reactivity і вперед на флатер. Ну хіба що роботи більше поки що на реакті

Хоча логічніше було б продовжити ларавель плюс до нього вуе вивчити. Дохерища роботи на апворку по цьому стьоку.

«Ах вона оно чё, Михалыч!» ©
Фрилансеры могут не беспокоиться — на их век работы на PHP хватит.

>реакт це труп

Сильна заявочка. Перевіряти її, звісно, ми не будемо.

Как я понимаю, автор заявочки забыл дописать «на десктопе». И здесь он в чём-то таки прав — как только на десктоп официально завезут Flutter с отрисовкой UI через skia, а не движок браузера — Электрону с реактом придётся потесниться. Flutter — это отличный middle-ground между «хардкором» Qt и костылём в виде необходимости браузера как UI движка.

В вебе — очень вряд ли что-то поменяется; разве что будет компиляция того же Dart в web assembly. Но от DOM в обозримом будущем никто никуда не уйдёт.

В мобайле Flutter уже сейчас активно отвоёвывает жизненное пространство. Но — есть нюанс: там, где важно сделать внешний вид приложения неотличимым от native mobile app — Flutter будет в вечно догоняющих, поскольку у него на 100% полностью своя отрисовка UI. Благо, сейчас даже на iOS уже намного меньше заморачиваются идеальным соответствием Apple UI guidelines.

Java яка один раз написана і запускається скрізь

Глючно, криво, ресурсоємко, при наявності JRE. Ще б мегапопулярний Flash згадав.

И от eclipse c intellij тоже? Как и от остального софта на java, которого сверхдофига..

Глючно, криво, ресурсоємко

Доказательств с примерами альтернатив конечно же не будет )

Ти сам приклад навів. Екліпс — глючно, криво, ресурсоємко.

работал на нем, на STS, как и вся компания.
ерунда какая-то про

глючно, криво, ресурсоємко

как и выше

Ну не нормальним віндовим аплікейном воно виглядає.

тоже странно
ведь SWT так и задумывался, использует нативные средства ОСи для UI. В отличие от Swing (AWT вспоминать не будем)

З під Лінукса запускав?
1. Грузиться довго, та і взагалі підглючує.
2. Робота з Рімоут файлами — просто казка — коли все висне при обриві інтернету, і не зявляється після того як інтернет власне зявився.

З під Лінукса запускав?

ні, якось не мав потреби :)

по 1 не знаю про що. довше за всіх стартують IDE від JetBrains
по 2 — не було ще потреби у такому кейсі, теж не пробував

мабуть так, з вашими кейсами розробки Екліпс вам не підходить.

Eclipse десь так само стартує

может бути

просто я як я жартую
IDE у програміста повинно бути у автостарті
і чому його треба по декілька разів на день запускати — не дуже зрозуміло...

тобто критичність часу старта взагалі — незрозумілий критерий
в мене IDE тиждень працює, бо тільки в неділю перезавнтажую комп. у профілактичних цілях :)
тобто стартує — раз на тиждень.

звісно є й таки кейси розробки коли кожні пару годин програміст запускає свою основну IDE, але якось незвично мені.

Ну це просто параметр який легко вимірюється «оком»

Доказательств с примерами альтернатив конечно же не будет )

Я користуюсь intellij. З переліченого вище — воно лише ресурсоємко, на машині менше 16Гб РАМ — не уявляю як воно. Альтернатива екліпсу не джавішна — Атом. Шустро, рівно, легко, але — нажаль сиро. Можливо наразі.

Альтернатива екліпсу не джавішна — Атом.

А альтернатива ms office это notepad++

Я користуюсь intellij. З переліченого вище — воно лише ресурсоємко, на машині менше 16Гб РАМ — не уявляю як воно.

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

А альтернатива ms office это notepad++

Якщо для моїх завдань достатньо нотпад++ я не буду юзати офіс. Екліпс сильно заточений під джаву, решта його інтеграцій які я юзав написані не ахті, і в них профіту з атомом не так і багато по функціоналу. Зате по юзабіліті — атом набагато кращий.

Java
Глючно, криво, ресурсоємко

Ага, прохладные былины 15летней давности.

Щодо JRE — я так розумію притензій нема?) Це типу така ж кросплатформенність — якщо аплікуху на докері розгорнути?

Шедевр )))

Ніколи не бачив жодного UI на Java, яке було красивим й нормально б працювало без глюків. До того ж «запускається скрізь» воно дуже умовно. Для початку треба проінсталювати саму Java, потім розібратися (якщо ми говоримо про Linux), яка з них нормально працює (напр. той самий Eclipse на OpenJDK колись гальмував й глюкав) й розібратися з alternatives й налаштуванням машини, щоб їй пам’яті вистачало. Далі раптом (у випадку NetBeans) може виявитись (що цікаво, вже після інсталяції), що йому треба не JRE, а JDK, яке щоб завантажити треба ще й реєструватись. Не смертельно — але незручно. Якщо згадати мобілки — все зовсім сумно буде.

Да описанные проблемы с энвами уже давно решаются dev-containers из под контейнеров можно легко запускать любую IDE которая надо с любым энвом и свою систему оставлять девственно чистой. а на счёт глюков IntelliJ IDEA на том самом линупсе работает восхитительно без багов и тормозов.

Ніколи не бачив жодного UI на Java

Можно подойти к любому разработчику и посмотреть на его иде.

Спробуйте скористатися гугл-траслейтом, якщо не зрозуміли речення.

~2 роки назад треба було зробити для клієнта десктоп додаток. Вибрали електрон, тому що:

— Всі демо Qt які я бачив виглядали так ніби їх робили студенти за їжу
— Фронт девів в 10 раз більше чим Qt
— За Qt треба платити

Інших альтернатив особливо і нема. Проект зробили, клієнти супер задоволені. Один з найшвидших наших проектів.

Именно. Прямота рук решает гораздо больше, чем технологии под капотом.

И на Электроне можно писать по-нормальному (та же VS Code отлично и быстро работает), так и на любой другой технологии можно рукожопить.

Есть сомнение, что одной только прямотой рук можно вообще все решить. Да и иной раз еще поди найди настолько ровные руки. Я хз как и почему, но вот не давно обнаруженный баг/фича это расшаренные настройки прокси между хромом и приложениями на электроне изрядно подпортил жизнь. Система Kubuntu проблема была со slack и mattermost.

Внезапно, на Windows многие десктопные приложения тоже берут настройки прокси из Internet Explorer.

Это как раз не неожиданность.

А можете назвать еще пару приложух на Электроне которые нормально работают кроме VS Code?

Typora и Slack (ну у меня, по крайней мере, он работал совершенно нормально).

Есть куча более легковесный редакторов для этого и удобнее.

Под Винду, и с WYSIWYG? Порекомендуй плиз. Под Мак видел, под Винду в своё время ничего вменяемее Typoria не нашёл.

Python + GTK...

Для Линукса логично, но как связка для кросс-платформы — то не очень. GTK на Windows выглядит в большинстве случаев коряво.

Понимаю, что лично тебе может быть и насрать, но мы обсуждаем альтернативы Электрону, а не личные предпочтения.

Под Мак видел, под Винду в своё время ничего вменяемее Typoria не нашёл.

CuteMarkEd cloose.github.io/CuteMarkEd — ИМХО вполне норм. markdown-редактор (на QT). По-крайней мере мне зашел. Typoria не юзал, поэтому насчет нее ничего сказать не могу.

Есть прекрасный плагин под FireFox, а редактировать можете хоть в Far-e.

Та даже ж впф подошла б с блеском. Но им же кроссплатформа нужна была скорее всего.

За Qt в більшості випадків не треба платити, можна використовувати LGPL ліцензію.

Шо, опять срач за Qt? Viber for Desktop тоже выглядит «ніби студенти за їжу»? Может быть, Telegram навел вас на такие мысли? Или зачем далеко ходить, QtCreator который просто ракета, по сравнению с бегемотами от JetBrains? И кто с вас требует деньги, вы про LGPL вообще в курсе?

А разве в Бресте есть ПВТ?

Там все можно сделать. Видимо, поддержка HiDPI настолько «актуальна», что ее даже не тестируют.

Пластмасовий мір побєділ?

тут не много людей найдется старше этой песни
www.youtube.com/watch?v=RW3ItR4LPMY

А кто-то такое и вообще не слушает 💁🏼‍♂️

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

Чому збочення у вигляді електромобілів стали нормою?

Чому збочення у вигляді інтернет-банкінгу стали нормою?

Більше місця для картинок, відосиків і тексту. Популярність iPhone.

Чому збочення у вигляді лоукостів стали нормою?

Кстати, мне не очень, серьезно, часто ложные срабатывания, неудобно держать, нет тактильности от клавы...

но все же бесит отсутствие двухуровневой физической кнопки для фотоаппарата и «назад», как у моего первого Omnia II. И какой идиот придумал фотать по тапу...

На айфонах можно фоткать кнопками ±для звука, можно зажать и щелкать серию.

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

Дабл тап по кнопке блокировки запускает камеру. Если есть локскрин тоже запустит, но с ограниченным доступом в папку с фото.

На Sony Xperia є така кнопка, і дворівнева )

Люто пiдтримую!

Що з нами стало? Пластмасовий мір побєділ?

просто багато програмістів добре знають як писати Web UI

а програмістів які можуть писати GUI для десктопу — невплинно меншає
бо програміста Web UI можна безболісно перекинути доробляти сайт, а гуйового — ні

тому програміст Web UI вигідніший.

те ж саме з Node js на бекенді, ніяких таких технічних переваг в неї нема.
зате повно — людських ресурсів, які можно трохи довчити, перевчити писати бек

Тобто відповідь на питання змін у технологіях треба шукати не в технічній сфері, а в соціальній та економічній

і про Delphi теж.

і про

Netbeans

я і зараз на ньому.
І на Swing’у писав. І легасі проект якось сапортив. Класичний, від індусів. Жахіття, як був написаний на академічному Swing’у...

Але роботи все меншало і меншало.
а у програміста Web UI все більшало і більшало

А потім до вебу додались смарти, та й все — десктопний GUI став зовсім маргінальною потребою.

Класичний, від індусів. Жахіття, як був написаний на академічному Swing’у...

Зачем в пятницу писать людям такие вещи?

та может кто не видел.
или банковские клиенты

а делов то, накинул LaF и все, красивеньких, няшных то много было.
и под нативный вид GUI операционки тоже.

но это снаружи

а внтури то...

я и на Дельфи видел, прям из UI — и в базу полез
а на Swing из потока UI...

Тих хто шарить в вебовий ГУЙ ще менше ніж тих хто вміє в десктопний.

тобто сайтів з складним UI менше аніж десктопних аплікацій?

Гарний приклад сучасний шлак типу Телеграма

я б все ж не плутав UI та UX
проектування інтерфейсу то інша справа

жахливий UX і на гуях був не рідкістю

Цікаво те, що у нас на одному проекті звіти так само працювали: спочатку качалися на клієнт, а потім вже вискакував діалог куди це зберегти

так :)
бо так простіше всього

Мені пояснили, що це новітні досягнення інженерної думки в ангулярах.

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

може й «Пластмасовий мір побєділ»
але от я все частіше замислююсь, то що, мені переважно бекендеру готуватись до TypeScript, чи поки зарано?

як не називай, але ж риса програмування — постійні зміни. навіть якщо у сумнівний бік

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

Програмування це ж не інженерія.

о, нечасто можна зустріти однодумця серед колег програмістів :)

було колись, я ще застав, як молоденьким був.

Прогрес заради прогресу не потрібен

але він про це не знає

в скайпе сидит бизнес и некоторые жирдяи с баблом, которые держат целые галеры. Хотя скайп, как его переписали на реакт и привязали к аккаунту М$, стал еще хуже говнищем чем был, бесит невероятно

его как раз на электрон переписали

Ну для Pidgin є плагіни для підтримки Telegram і Discrod. Користуватися Telegram через Pidgin незручно.

  • Немає розділення на групові і приватні чати — все звалено в купу. До того ж чати в списку постійно міняють свою позицію в залежності від кількості повідомлень.
  • Сповіщення зʼявляються навіть тоді коли хтось просто пише в чаті. Доводиться для кожного групового чату відключати сповіщення.
  • На відміну від Pidgin не можна змінити шрифт. Наприклад, хочу щоб була Verdana.
  • Налаштування DPI не впливають на розмір шрифтів в Telegram. В Telegram можна змінити масштаб UI, але це масштаб саме GUI а не тільки розмір шрифту.
  • Привʼязка до номеру телефону.
  • Текст повідомлень в Pidgin читається легше ніж в Telegram.
  • Засилля картинок, картинок зі сміщнявками, фоточок, відосиків з часом починає дратувати і є причиною додаткових витрат енергії.
  • Той же Jabber дозволяє підняти власний сервер і писати клієнти які хочеш. А Telegram це один централізований сервер і клієнт твій можуть легко заблокувати.
  • Не зрозуміло, принаймні мені, що з Telegram має Павлік. В FAQ написано що «We believe in fast and secure messaging that is also 100% free.» і що «Pavel Durov, who shares our vision, supplied Telegram with a generous donation, so we have quite enough money for the time being». Може це задум спецслужб і все зливається самому Пу? Може Павлік барижить всілякими даними зібраними з користувачів Telegram?
  • Ну і в цілому там повно хомʼячків яким не набридає в стотисячний раз показувати всім картинку про it’s wednesday my dudes і які, як мені здається, тільки вчора почули про якісь там чати.
Але воно не таке гидотне як Discrod.

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

Пятничный вброс.
На заезженную до дыр тему.
Ничего нового :(

Чому заїзджену? Нечасто ж подібні теми піднімаються.

запускаються і працюють однаково що під Windows що під GNU/Linux

Що під андроїд? ой.. ні..
А то саме в веб морді можна?
От тому і стали.

Недавно вийшов проект Tauri tauri.studio/en Це заміна electron, крім того його бінарники менше 3 MB. На Rust 😎

Есть NodeGui или как там его. Javascript + Qt.

Як бачу Rust, плюсую не читаючи ;)

The first generation User Interface in Tauri apps leverages Cocoa/WebKit on macOS, gtk-webkit2 on Linux and MSHTML (IE10/11) or Webkit via EdgeHTML / Chakra on Windows.

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

Конечно, если запихивать в этот Tauri сайт, который и так приходится тестировать под Safari, то проблемы особой не будет. Но и смысла в таком «приложении» — тоже. Особенно с учётом того, что PWA на носу.

Тут поруч в Відні є вакансия на COBOL. Не бажаете спробувати?

Ніт, тільки лимонад Буратіно

А в якості премії — згущене молоко

А вместо зарплаты — грамота с подякой, и путевка в лагерь для детей.

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

Еееех.. Я вважав Вас олдфагом. А у Вас просто п‘ятниця )-

якщо згадати про те що вже 100 років як в якому-небудь Delphi можна однією рукою накидати програму з GUI

«одной рукой накидать прогу с гуем» — это про вот эту прогу -> hiasm.com . Ну или про шестой вижуал бейсик. :-) ...Хотя...наверное и на дельфях можно было свой блокнот за 10 минут состряпать)

Pidgin, Cherrytree, Qbittorrent, Netbeans і т.д. запускаються і працюють однаково що під Windows що під GNU/Linux. Що з нами стало?

Pidgin — ИМХО морально устарел как и прочие аськи.
Cherrytree — хз, не юзал.
Qbittorrent — юзал, юзаю и буду юзать. Ибо ИМХО самый кошерный торрент-клиент)
Netbeans — вполне себе жив-здоров, есть уже версия 11, хотя мне кажется, что большинство «нетбинсников» до сих пор юзают 8.x-версии нетбинса.

Пластмасовий мір побєділ?

Моя оборона — солнечный зайчик Python + PyQT / WxPython / etc. :-) Вполне себе кроссплатформенно и как по-мне не хуже разных электронов (по крайней мере в плане «хуяк-хуяк-и-в-продакшн»). Хотя конечно да, электрон — это "стильно, модно, молодежно"©

«одной рукой накидать прогу с гуем» — это про вот эту прогу -> hiasm.com . Ну или про шестой вижуал бейсик. :-) ...Хотя...наверное и на дельфях можно было свой блокнот за 10 минут состряпать)
Pidgin — ИМХО морально устарел как и прочие аськи.

Як і чатики взагалі? Не суть.

Из того, что я знаю/юзал/юзаю навскидку: Pyzo, Spider, Ren’Py, Eric, ну и естесно IDLE. Правда это все редакторы для самого питона (вот мне Pyzo очень даже нра как редактор/IDE для питона). Думаю 100% еще какие-то более-менее известные приложения есть (просто я как-то не сильно интересовался количеством гуи-приложух на питоне).
Просто все привыкли к разного рода пайчармам, атомам и вижуалстудиям (не считая разных идешек на плюсах), в то время как работающую приложуху с гуем вполне и на питоне можно сделать, а если питон для гуя — это «пальцев одной руки хватит», так это жалко, ибо питон для гуя вполне годнота (ИМХО).

пользователь хочет халявы, а бизнес ищет пути удешевления.

Где же тут удешевление? Сейчас фронтенд — синьоры стоят дороже специалистов по ИИ и бигдата-ученых!
А насколько сложнее написать, например, Email клиент или магазин на жабаскрипте по сравнению с ASP или JSP — это и говорить не приходится!
Вот малый список того, что в нормальных языках есть «из коробки», а во фронте прикручивается через боль и страдания:
— Обработка ошибок
— Телеметрия и логирование
— Работа с таймзонами
— Локализация, разные языки
— Разные форматы дат, времени, валюты.
— Зеркальное отображение (RTL).
— Многопоточность, асинхронность, синхронизация.

Ну чушь же. Возможно, никто не пишет новые приложения на JSP, потому что условно говоря «рыночек порешал», а не потому что кастомерам хочется платить больше денег?

— Обработка ошибок

В каком месте она в JS через боль и страдания?

— Телеметрия и логирование

Телеметрия в плане анализа поведения юзеров? По-вашему, есть разница в прикручивании аналитики на приложение на JS или на JSP? Или если пойти дальше, то AppDynamics / New Relic / etc, вместе с мониторингом серверной части и инфраструктуры они еще и для фронта трекать умеют.
Логирование — хз, из того что я видел, это что в C# коде выглядит как logger.log(), что на фронте.

— Работа с таймзонами

Есть нативные методы типа Date.getLocaleString(), ну или в куче проектов есть moment.js, который дает еще больше функционала.

— Локализация, разные языки

i18n

— Разные форматы дат, времени

Это и нативные методы умеют, если не нравится, то вышеупомянутый moment.js.

валюты.

Тут не сталкивался, но точно ничего сложного тоже.

— Зеркальное отображение (RTL).

Это жопа, да. А что, в JSP есть магические методики, которые вам интерфейс под арабский сделают из коробки?

Многопоточность, асинхронность

Многопоточность — чего нет, того нет. Только в воркер можно вынести отдельный поток, если что-то очень затратное посчитать надо.
Асинхронность — ну как бы весь JS построен на асинхронщине, и что с ней не так? Хочешь — промисы, хочешь — обертка в виде async/await чтобы выглядело прямо как в C#, хочешь реактивщины — RxJS к вашим услугам. Что-то я не слышал, чтобы у кого-то асинхронность была «через боль и страдания». Тем более что и нативный fetch есть.

— Зеркальное отображение (RTL).

це ніби в css є і там для подібних речей останнім часом почали доволі сильно розширювати можливості, ну якщо не потрібно щось стареньке сапортити звісно, що в випадку електрона не буде проблемою

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

Отмечу свое мнение — в JS раздражает отсутствие нормального IDE типа Visual Studio. Не Code, где даже шорткаты толком не назначить, а именно VS IDE, чтобы можно было бы прицепиться к инстансу броузера и посмотреть что JSного он там исполняет.

чтобы можно было бы прицепиться к инстансу броузера и посмотреть что JSного он там исполняет

Внезапно, в VS Code это можно сделать для любого браузера на движке Chromium.

А вот в Visual Studio раньше было можно только к IE с его Microsoft scripting engine. Возможно, сейчас уже и поддержку Chromium тоже запилили.

Я не случайно сказал про шорткаты от VS. Code их хорошо если на треть позволяет назначить. Плюс настроить шрифты как в полноценной VS — пичальбяда.

Шрифт редактора точно настраивается, сам это делал.

А остальные шрифты (именно шрифты, в смысле typeface) не очень и понятно, зачем настраивать...

Все там настраивается, VS Code один из самых гибких и быстрых современных редакторов. А уж с JS и TS работает как IDE из коробки.

Попробуйте настроить там Ctrl-Q на закрытие окна с редактируемым документом. Или Ctrl-W для выделения слова. Год назад мне люди за деньги не смогли этого сделать, не поломав другие шорткаты в VS Code.

Может просто руки не из тех мест?

там мышление менять нужно
в JS пара концептуальных моментов которые сильно отличают JS от привычного «C++» мейнстрима

молодые не отягощены — вот и фигачат, не зная что JS плохой
плохо ж на нем пишут не потому что он плохой — а потому что молодые. они плоховато бы на чем угодно писали.

Это видимо какой-то юмор, но для меня это слишком тяжело....как и с++

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

а как понял, так и легче и стало общаться :)
то есть посмотрел на мир их глазами, через JS

в конце концов кто взрослее — тот и может понять младшего, а вот наоборот — шишь.

но для меня это слишком тяжело

да, я в курсе

Вторая причина появления и относительной популярности TypeScript — замаскировать JS под привычные концепции.

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

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

вы просто нормальны, и все :)

бизнес, ничего не попишешь

как помнится читал, жаловался, кажется, Микиланджело на жизнь
заипали эти апостолы и девы марии.
но — только за них и платят.

ниши всякие бывают

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

так что да, каких вакансий только не бывает.
и для спецов не говно — тоже бывают

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

— Обработка ошибок

Что с этим не так на JS?

— Работа с таймзонами

momentjs.com/timezone

— Локализация, разные языки
— Разные форматы дат, времени, валюты.

По большей части есть из коробки во всех современных браузерах:
developer.mozilla.org/...​rence/Global_Objects/Intl

Сторонние решения тоже в наличии:
medium.com/...​8n-libraries-657f9fd2124a

— Зеркальное отображение (RTL).

rtlcss.com
Ну а собственно поддержка RTL есть в CSS.

Многопоточность, асинхронность, синхронизация.

Есть асинхронность через async / await. Большего для GUI и не нужно.
Многопоточность и синхронизацию в GUI использовали тогда, когда не было более высокоуровневых средств запустить код асинхронно.

Есть асинхронность через async / await. Большего для GUI и не нужно.

Неправда.

Что неправда? И что вам нужно на фронте из многопоточности?

Как насчет синхронизации запросов? Дождаться пока загрузятся все данные, а не каждый запрос отдельно?

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

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

GraphQL — универсальное решение
но, недостатки и у него есть
другие просто

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

а читают все
поэтому лучше ответить полнее, чем был конкретный вопрос
по моему.

по разному делают

но я предоставляю фронтенду такой API где он может запросить все сразу

вообще, проблемы с фронтендом часто в том, что бек предоставляет API не рассчитанный на типичные сценарии на фронтенде
а фронтендеры молчат об этом

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

но хотя бы он понял что в приемке API — он главный, фронтенд, а не бек
серваку легко справиться с любыми «неудобными выборками»

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

причем, так куча учебников учит.
авторы не перестроились еще.

никуда не денутся :)

их просто перестанут читать
а будут читать какого-нить Дугласа Крокфорда, да «Вы не знаете JS», Кайла Симпсона

читал обоих, вот и интервью:.
Кайл Симпсон: в JavaScript я забыл больше, чем большинство людей вообще знали
techrocks.ru/...​3/kyle-simpson-interview

как по мне — толков. но по другому чем классические программисты :)

как нельзя было даже в СССР остановить увлечение хэви метал (как нас только не песочили), так и тут, фик получится уесть молодых кому JS зашел

И этого не случится.

уже случилось

мой фронтендер, которого команда субподрадчиков уже окрестила «Бог фронтенда», за скорость разработки
вообще учился по ютьюб курсам

не читал вообще толком ничего, и профильного образования нет.

общаться надо с молодыми, поймете :)

не на форумах только.

а ведь это еще так. цветочки

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

«сплав по Днепру» — это ж не столько возраст когда уже на работу не берут
а прежде всего когда перестал видеть изменения вокруг

с детьми, а не идиотами :)

а так, выбирайте сами конечно

Дети — это до 3-5 класса школы.

дети — это состояние
половозрелость не гарантирует взросления

А дальше или становятся идиотами

не факт. период взросления просто затянулся :)

Ты оптимист

зависит с какой стороны смотреть :)

точно не стану топом
не люблю галеры, ни в каком виде :)
хотя, наверное это скорее они меня не любят, а я уже так, им в спину
я вне их формата.

вон новый реакт вышел.

Это если еще очень повезет, это типа сеньйор ботан фронтенда, а так реакт слишком сложен, так что vue- вот реальность ))

Есть Promise.all([promise1, promise2, ...])

import { useEffect, useState } from 'react';

import BrandsService from '@services/BrandsService';
import ProductsService from '@services/ProductsService';

export default function useMainPageBootstrapData() {
    const [error, setError] = useState(null);
    const [isLoading, setIsLoading] = useState(true);
    const [data, setData] = useState({});

    useEffect(() => {
        const promises = [
            BrandsService.fetchAdwSliders(),
            BrandsService.fetchAll(),
            ProductsService.fetchBrandnew(),
            ProductsService.fetchTopseller()
        ].map(async (pr) => pr.catch((e) => setError(e)));
        let isMounted = true;

        (async () => {
            const [adwSlidersData, brandsData, brandnewData, topsellerData] = await Promise.all(
                promises
            );

            if (isMounted) {
                setData({
                    adwSlidersData,
                    brandsData,
                    brandnewData,
                    topsellerData
                });

                setIsLoading(false);
            }
        })();

        return () => {
            isMounted = false;
        };
    }, []);

    return {
        isLoading,
        error,
        data
    };
}
— Обработка ошибок
Что с этим не так на JS?

Проблема что ее просто нет!
Сейчас в моде позитивное мышление. Если задаешь клинету вопрос что должна делать программа если что-то пойдет не так — он просто не понимает вопроса! Все требования, все юзер стори, все тесткейсы и примеры описывают только успешные сценарии. Потому что некогда думать про ошибки — нужно быстрее пилить новые, успешные фичеры.
Ну ок — предположим у нас вся команда с позитивным мышлением. Ошибок никто не ждет и никак не обрабатывает.
Что будет с программой на C#, в которой вылетит любая ошибка? Пользователь увидит сообщение и программа закроется.
Что происходит в SPA на жабаскрипте? С точки зрения пользователя — абсолютно ничего! Он не увидит никакой ошибки если кто-то из девелоперов не напишет какой-то способ эту ошибку ему показывать. А если ошибку вернул сервер, а колбек есть только на success (в большинстве приложений я видел именно такое)?
В итоге от пользователей постоянно прилетают баги такого вида:
— Я не могу найти нужного контрола (а он не нарисовался — упал)
— Спиннер не перестает крутиться (все ждет успешного ответа от сервера)
— Я нажимаю на кнопку — ничего не происходит (а другая кнопка рядом — работает)
— Я сохраняю данные, оно показывает новые — а потом возвращает старые (не сохранило на сервере).
При этом все что может предоставить самый продвинутый юзер — это скриншот! И как можно понять что у него пошло не так не видя ошибки?
Тем более что фронтенд приложение не останавливается от ошибки. Юзер нажал раз — вылетела ошибка, он полез в другое место — и приложение продолжает работать уже неправильно!
Да — на жабаскрипте все это можно похэндлить, залогать, прикрутить показ ошибок... Но это нужно делать, об этом нужно постоянно помнить, в то время, например как на C# ошибка вылетит сама, юзер поймет что что-то пошло не так, перегрузит страницу и возможно ошибки уже не будет (если это был, например, обрыв связи).

Да — на жабаскрипте все это можно похэндлить, залогать, прикрутить показ ошибок...

в действительности не так уж и сложно.

если в требованиях к проекту такое будет, то делается

А если ошибку вернул сервер,

то он ее залогировал

вернуть же должен фронту понятную, кодифицированную
тогда и при тестировании фронта видно что произошло, и вывести можно
и даже — перезапустить SPA, для класса ошибок

Юзер нажал раз — вылетела ошибка, он полез в другое место — и приложение продолжает работать уже неправильно!

это зависит от того как спроектировано SPA
как там работа с «store» организована

вобщем SPA — это не тупая консоль, а отдельная часть приложения, которая и должна так разрабатываться

Конечно не будет! Тем более что пользователи не видят ошибок. Ну пожалуется один юзер из тысячи — так зачем тратить время на обработку ошибок? А потом еще тратить время тестировщиков что бы проверять что ошибки действительно обрабатываются.
У нас вон целая очередь фичеров, которые нужно сделать что бы обогнать конкурентов. Сейчас кто первый выбросил в продакшин хоть как-то живую версию — тот и молодец. Если уже очень забагованная получилась — то починим «по многочисленным просьбам».
Вы посмотрите как игры делают: большинство игр просто нельзя пройти пока пару патчей не выйдет. Банально рабочие только первые уровни — что бы купили. Если игра хорошая — то фанаты сами пачтей напилят и все исправят. А если плохая — то нахрена чинить?

Ну пожалуется один юзер из тысячи — так зачем тратить время на обработку ошибок?

да, за одного пользователя никто бороться не будет

У нас вон целая очередь фичеров, которые нужно сделать что бы обогнать конкурентов.

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

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

все так.
универсальных рецептов нет.

Если игра хорошая — то фанаты сами пачтей напилят и все исправят. А если плохая — то нахрена чинить?

совершенно верно.
что в этой логике не так?

а кто это?
компанию знаю, а пользователя такого — не знаю

а, заказчиком выступали

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

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

я о других пользователях говорил :)

Таким пользователям на Интеле в то время не доверяли

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

у нас есть.

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

проекты разные бывают. как и требования к ним.

Пока один будет пилить обработчики ошибок, другой уже выкатит 10 новых фич.

и вся выгода от скорости испарится при выкатке 11ой фичи

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

А как язык программирования защитит от такого?

В любом языке можно игнорировать ошибки и исключения.
Что мало таких которые все в try — catch забросят?

Проблема что ее просто нет!

Уморительно :)

С точки зрения пользователя — абсолютно ничего! Он не увидит никакой ошибки если кто-то из девелоперов

Еще со времен первых SPA на бэкбоне и предшествующих ему MV* велосипедов логируют ошибки на фронте с агрегацией на сервере. Это было весьма важно в те темные времена, потому как обязательно найдется клиент, у которого все может поломаться из-за вольного трактования стандартов и войны браузеров и ты об этом мог никогда и не узнать из-за огромного их зоопарка и отсутствия всяких сервисов тестирования типа browserstack или Sauce Labs и прочего жира.

Но это нужно делать, об этом нужно постоянно помнить

Делать что? Зайти на npm и импортировать любую библиотеку?

например как на C# ошибка вылетит сама, юзер поймет что что-то пошло не так, перегрузит страницу и возможно ошибки уже не будет

бугага) Шикарное поведение. Ну нате распишитесь:

window.onerror = (message, url, line, col, err) => {
    fetch('/log', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json;charset=utf-8'
        },
        body: JSON.stringify({message, url, line, col, stack: err && err.stack})
    });
    if (confirm('Unhandled exception has occurred in your application. '+
        'If you click Close, the application will ignore this error and attempt to continue.' +
        `If you click OK, the application will restart immediately\n\n${message}\n\n${err && err.stack}`)) {
        window.location.reload();
    }
};
(если это был, например, обрыв связи).

перегружать приложение, если был обрыв связи ))) это офигенно же для веб приложения)

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

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

вменяемый и читаемый эксепшен

Ага-ага. NullReferenceException или InvalidArgumentException. И далеко не всегда с какой-то полезной поясняющей информацией. Не приходит мысль, что полезность диагностической информации зависит гораздо больше от программиста, чем от рантайма?

меседж пишет вообще левую херню, что там пакет какой-то сломался

Даже любопытно, как вам удалось получить такую ошибку в рантайме.
При сборке бандла — да, бывает. Так и в дотнете NuGet порой чудит.

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

Второе, исходники дотнет либ решарпером декомпилтся в джва клика, все видно и читабельно.

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

Джава скрипт это позор и черная порнокомедия современного IT, который должен быть стерт и забыт.

Даже результат вывода этих пары строчек вполне:
✔️ читаемый эксепшен
✔️ стэк трейс
✔️ строка в коде где ошибку выкинуло
❌ в говноскрипте информации ноль

Unhandled exception has occurred in your application. 
If you click Close, the application will ignore this error and attempt to continue.
If you click OK, the application will restart immediately

Uncaught TypeError: options must be an object!

TypeError: options must be an object!
    at EventEmitter.<anonymous> (http://localhost:63342/EventEmitter2/worker.html:29:15)
    at EventEmitter.emit (http://localhost:63342/EventEmitter2/lib/eventemitter2.js:374:19)
    at http://localhost:63342/EventEmitter2/worker.html:31:29
Где же тут удешевление?

Удешевление в переносе на клиент вычислительной мощности. На объёмах уровня всяких фаангов — а в основном они и повыдумывали все эти фронтенд фреймворки — это очень существенное удешевление на серверных мощностях.
Просто пользуются этими технологиями далеко не только компании масштабов фаангов. Ну и сами себе злобные Буратины.

Мова була не про таке здешевлення, а про різницю в витратах на оплату умовних програмістів на Qt які напишуть нормальну програму і web-програмістів які наваяють HTML документ з JavaScript, засунть в Electron і потім будуть це розповсюджувати під виглядом нормальної програми. Як одна з причин розповзання всякого електрону називалася дешевизна вебщиків в порівнянні з більш нормальними програмістами — поганенько і криво зате дешево.

Мне тут нечего сказать, я на десктопе писал только на делфи, МФЦ, и винформс. Почему выбирают электрон а не кьют не знаю. Но думаю должнв быть причины, в массовую иррациональность не верю.

Причина элементарная — к Qt до недавнего времени не было других нормальных биндингов, кроме C++. А умельцев в C++ мало того, что дефицит — так это ещё и, в основном, «старая гвардия» со, скажем так, излишне основательным подходом к разработке софта.

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

Теперь вот завезли NodeGUI, в котором можно писать в привычной фронт-ендщикам парадигме (поддерживаются React, Angular, потихоньку пилят поддержку Vue) — но, в качестве движка рендеринга вместо браузера используется Qt.

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

а я много лет пользуюсь wikidpad, наверное с WinXP. основной заметочник у меня на десктопе, синхронизирую с ноутом дропбоксом

на wxPython он. замечательно работает.

Так то-то и оно, что заметочник. Там, где достаточно внешнего вида стандартных UI элементов ОС (или приближённого к нему) — такие решения работают. Я сам одно время пользовался таск трекером на PyQt.

Но — народ приучили к красивостям (даже в офисных и productivity приложениях), а вот тут уже одной обёрткой на Python над wxWidgets, GTK, и даже Qt без QML не обойтись.

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

использует оно только QtWidgets, а это уже не торт

С каких делов «не торт»-то? Сейчас native platform GUI look & feel мало кому интересен.

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

Рано или поздно и акселерацию завезут. Вчера уже находил один пулл-реквест на тему OpenGL, но автор пока забил.

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

Слава б-гу что не блятский хромиум.

А если собираются толпа

то это peopleware
и
— как проект?
— да как обычно — как будто 50 пьяных обезъян пытаются сложить пазл.

но, зато знают по надцать оптимизаций сортировки
Психбольница в руках пациентов!

Но именно такое чаще всего и требуется.

здесь уже дело мировоззренческое
кто-то видит в этом чей-то злой умысел, чью-то волю, падение нравов, закат золотой эры
кто-то — свойсва и следствия какого-то процесса

большинство людей — теисты(верующие в Абсолют) и традиционалисты(золотая эра всегда прошлом), и поэтому предпочитают объяснять все первым.
а тех кто намекает что раз термину «Кризис программного обеспечения» столько лет, то стоит искать-изучать процесс, который приводит к этому «кризису» — обычно высмеивают как «альтернативно одаренных». всем же понятно что это рука диавола, всем же понятно что от Бога отвернулись, вот и получили Electron!

вопрос мировоззрения, искать ответ на простой вопрос
почему код другого читать сложно и легче написать свой?
(математики тоже говорят что многие доказательства лежать непроверенными годами, потому что — сложно это)
в падении нравов.

и правда, чем же обяснить, что вот был «Дельфи», ну и наращивали б GUI опыт, а не начинали все с нуля да еще на неподходящем языке разметки текста.

А в реальности рулят лень и глупость

из чего можно сделать выводы

HTML, CSS, JS для UI не может быть сложнее предыдущих технологий
а если глупость и лень побеждают — то значит и проще предыдущих технологий

качественнее

есть имеет два смысла
— перфекциониское
— и как соотношение затрат к результату (ботинки которые носятся максимум месяц и стоят 3 копейки — качественные)

легче

потому что

в реальности рулят лень и глупость
дешевле

потому что легче, а значит раб сила — дешевле, в среднем:

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

Обычно труднее, дороже и говеннее.

первые два пункта не сходятся с

в реальности рулят лень и глупость

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

говеннее да. ок. см о качественности ботинок за 3 копейки

Может потребители и иррациональны — пользуются медленным, тяжеловесным приложением. Но иррациональный бизнес долго не выживает.
Мне просто тяжело оценить, потому что ни с Qt, ни с электрон никогда не работал и не представляю плюсы и минусы каждого, легко могу ошибаться.
Но чуйка подсказывает, что разработать приложение с богатым UI на электроне в разы быстрее, чем на с++.

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

нит. см на QML

Є ще .NET із його Webforms, якщо не подобається жаба та хрести. Шарпік — гарна чистенька мова, я б сказав як мова краще жаби. Не так легко йде на мобілах та лінуксі, але таки йде і працює швидше за електрон.

По-моему на .Net сейчас можно написать ну все, что угодно! На полноценном C# языке, без колбеков и замыканий, без «эмуляции» ООП и асинхронности. В удобной IDE, с нормальным дебагом, с подсказками, юнит тестами, профайлерами, решарпером и всем, о чем может мечтать девелопер для удобной разработки. Уже и ИИ прикрутили что бы код дописывал за ленивыми.
Нужно быть упоротым мазохистом что бы вместо этого билдить ноду и жабаскрипт в консоли, дебажить через анус и постоянно наступать на грабли когда пропустил букву в названии.
Не знаю с чего решили что порог входа в жабаскрипт ниже, чем в C#.

Ну а дальше что, с GUI что делаем? Особенно если нужно кроссплатформенность. Вот Майкрософт, вместо того, чтобы допиливать WPF, адаптировать его под .net core, написали VSCode на электроне.

Особенно если нужно кроссплатформенность.

Проблема кросплатформенности — искусственная! Разные производители специально делают все, что бы кросплатформенности не было, а все пользовались именно их «экосистемой»: своя ОС, свой язык разработки, свои IDE...
Поэтому когда говорят что мы сделаем приложение на жабаскрипте что бы было кросплатформенным — это все равно что «слепим пулю из говна».
Самая простая и дешевая «кроссплатформенность» — обычный веб сайт на HTML + CSS. Если написан правильно, без выпендрежа, то работает хорошо и одинаково на всех платформах!
Пытаться сделать GUI приложение кросплатформенным — изначально гнилая идея! Опыт Java это хорошо показал. GUI приложение нужно что бы использовать все возможности системы — а системы не одинаковые! Если же нужно что-то что работает одинаково — то не нужно GUI приложение, а можно сделать сайт.

Microsoft announced at Build 2018 back in May that they are bringing .NET Core to the Windows desktop applications frameworks, including both WPF and Windows Forms. This means that your client applications will be able to take advantage of the various performance improvements that have been introduced in .NET Core and that you will be able to deploy them as self-contained executables (.exes) that have no dependency upon any pre-installed version of .NET.

Есть такой проект Avalonia open source клон WPF, работает под Windows, Linux, MacOS

Не знаю с чего решили что порог входа в жабаскрипт ниже, чем в C#.

Он таки сильно ниже. Потому что в жабаскрипте нет хешмап, линекедлистов, еквалс-хешкод, потоков, и... да там вообще нихера нет!

и... да там вообще нихера нет!

и самое удивительное, как оказалось — да не особо то и надо!
а потом еще и Go вышел. правда Ноду ему похоже не одолеть уже. даже колбек хел не умерил ее победное шествие на бек. а теперь аwaitы с генераторами...

Посмотрим.
Но я начинаю подумывать что в будущем нас ждет тотальный JS кругом.
и драйвера даже будут траспайлиться с него в С

Electron дикая, адская ***та, это верно.

Пластмасовий мір побєділ?

Да

Electron дикая, адская хуита, это верно.

До сегодня не знал про него. Ну теперь нашему проекту жопа: не успели допереписывать на Реакт, теперь начнем переписывать на этот Электрон. Еще один зверь в нашем зоопарке!

Электрон это, по сути, NodeJS и браузер в одном флаконе. Вот в браузерной части код на Реакт прекрасно будет жить, как и жил.

Якщо замислитися, то використання HTML + CSS + JavaScript для написання програм це цілковите безумство і черезжопство адже вони створені для оформлення тексту.

Прочитал — и поймал себя на мысли что давно уже не писал чистый HTML и CSS. В современным фронте даже разметка и стили генерятся динамически жабаскриптом!

Пластмасовий мір побєділ?

Именно! Я еще помню как умные дядьки говорили что всегда нужно разделять код и оформление. Для оформления — декларативные языки: HTML, CSS, XML, XSLT, XAML и т.д. Таким образом дизанеры — художники могут делать красивое оформление не лазя в код. А девелоперы прикрутят логику к нужным событиям.
Смотрю на SAP приложение написанное в топ компании Долины на модных жабаскрипт фреймвоках. Что же я вижу? Проект собирается 10 минут (на хорошем серверном железе)! Дольше чем Делфи проект на х486 проце. Из этих 10 минут половину оно лоадит нод модули и всякие фронторые фреймвоки. Фолдер с этими модулями весит 5 Gb (больше чем весь Делфи целиком).
Потом идет компиляция тайпскрипта, линкование, минификация и т.д.
Когда-то JavaScript был СКРИПТОВЫМ языком — теперь же он компилится дольше, чем C++.
Абсолютно весь UI генерится программно. Какой-нибудь datepicker контрол — это тайпскриптовый файл на тысячи строк и уровень вложенности скобок такой, что нужен широкий монитор и горизонтальный скроллинг. Глядя на разметку в браузере понять какой кусок кода генерировал лишний див — это квест на пару дней.
Стили то же прикручиваются и меняются в коде. Раньше поменялась тема — просто другой css файл. Сейчас поменялась — код перегенерил все цвета ... но не везде. Еще два дня дебага что бы выловить в какой строке ошибка.
И хорошо бы если бы вся разметка генерировалось один раз. Но нет — у нас ведь Аждакс, а значит — все асинхронное. Разные куски сайта дергают сервер, потом им сервер отвечает, потом они себя рисуют. Открывая сайт никогда не знаешь: уже все загрузилось или через минуту появится еще один контрол. Ну а потом на любое действие пользователя начинается «каллейдоскоп»: одни контролы обновляются, дергают события, из-за них обновляются другие контролы, все мигает, везде крутятся спинеры... Юзер сразу видит что это очень динамичное и интерактивное приложение, а не унылая веб-страничка!

Що з нами стало?

Часто задаю себе тот же вопрос: почему UI стал самой сложной частью приложения? Весь бэкенд пишется легко и просто. Технологии обкатаны, паттерны разжеваны. Теперь, когда в моде микросервисы вообще праздник: не надо больше ковыряться в монолитах. Все стало настолько просто — что серверную логику начинают выносить в serverless!
При этом UI часть становится только сложнее и сложнее! Если раньше UI делали джуны — «формошлемы», а бизнес-логику и базу писали бородатые синьоры, то теперь всем нужны синьор — фронтенд — ангуляр — реакт — вуй — нода девелоперы.
Раньше был грех — тянули всю логику приложения в базу. Теперь другой грех — все тянут на клиента!
Я все жду когда клиент — банк приложения перепишут так, что бы они все расчеты проводили в жабаксрипте на клиенте — а результат сохраняли на сервер прямо в базу. Без сервеной валидации, естественно!
Остается надеяться что эпидемия и кризис помогут остановить это безумие. Бизнес начнет понимать что один хороший прочный трактор лучше, чем 100500 модных чудо — девайсов. И проблемы кросплатформанности-то никакой нет на самом деле. Обычный HTML + CSS, правильно сгенеренные на сервере будут работать одинаково на всех устройствах! Форма в 100КB вообще без жабаскрипта может выглядеть и работать так же хорошо, как фронтенд приложение весом 10МB. Вопрос как обычно «вам шашечки или ехать»? В сытые годы все хотят шашечки и с шиком, а в голодные годы будет уже не до выпендрежа.

я в свое время занимался в т.ч. и фронтом, а потом увидел эти тенденции и понял что хватит с меня этой фигни, буду только на бекэнде. Сейчас смотрю на эти все танцы с бубнами на фронте и вспоминаю с ностальгией flash/flex, который надо было просто развить и убрать минусы, а не убить под радостные возгласы толпы (я даже помню кто первый начал забивать гвозди).

причем технология хорошая же ж была.

Если бы она была такой хорошей, от нее бы не отказались.

На самом деле для пользователя то что есть сейчас намного лучше.
И не надо про монстроузность javascript, банеры на флеше отлично сбавлялись с подвешиванием браузера и съедением траффика.
При этом это все творилось в закрытой виртуальной машиной от Adobe.

Я уже молчу что это был отличный канал распространения вирусов. Так как Adobe никак не могли или долго чинили ошибки.

Баг с кирилей в Линуксе насколько помню чинили лет 6.

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

На самом деле для пользователя то что есть сейчас намного лучше.

Чим краще?

Слезы на очках — странные очки, а может слезы на лице,
DOS очистил все. Все, что было лишним у меня на диске С:,
Я нажал F8 и веселый Нортон удалял мне все подряд —
Сорок мегабайт, может даже больше, может даже шестьдесят.
Стили то же прикручиваются и меняются в коде.

Чем не угодил scss и плагины для его импорта?..

приложение написанное в топ компании Долины на модных жабаскрипт фреймвоках. Что же я вижу? Проект собирается 10 минут (на хорошем серверном железе)! Дольше чем Делфи проект на х486 проце. Из этих 10 минут половину оно лоадит нод модули и всякие фронторые фреймвоки. Фолдер с этими модулями весит 5 Gb (больше чем весь Делфи целиком).
Потом идет компиляция тайпскрипта, линкование, минификация и т.д.

Плюсую, виявляється, я не один, кого це дивує :-)
А ще там у node_modules кількість файлів зашкалює, покручє Linux kernel :-)
От взяти би іх всіх тих програмерів, і на дискети пересадити, щоб відчували, як системі больно, і що вони просто бездумно гвалтують вінчестери/ссд.

Самий яскравий приклад це шлак під назвою Slack.

гг

* Там навіть не можна зацитувати чуже повідомлення!

На самом деле, спустя год использования Slack я узнал, что можно, но ограничением: сообщение с приватного чата не может быть процитировано в другом чате, а только в этом же.
Функция называется Share message...

Вообще-то можно. Надо перед тестом цитаты поставить знак «>»

Використовувати «>» для цитування це класика, якою всі давно користуються, а не «не зовсім ручний режим». Як і markdown розмітка давно вже дефолт. Як і поведінка каналів.

Просто хтось наче вискочив з 2000 і не розуміє, що ми не в Фідонеті вже давно. А більшості подобається, тому що зручний інструмент для онлайн спілкування. Смайлики йому не подобаються, ти бачиш!

Пора успокоиться, что формошлепы пробрались на десктопы — электроны, на мобилки это react native и подобные говнофреймворки — работает, запускается, тормозит — ваша мобила хреновая, надо новую с 16ядрами и 1ТБ внутренней памяти свобоной. Галеры берут формошлепов, потому что делают продукт быстро на все платформы и дешево. Тажа самая история с вендой была, когда только дотнет появился — все кривились, ругались, что папочка c:\windows\microsoft.net все жирнеет и жирнеет, и успокоились, когда уже полвинды на нем написаон

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

Delphi можна однією рукою накидати програму з GUI

Разве что энтерпрайзное винформовское говно, да и здохло делфи уже давно

Qt

С++, спасибо, поблевал. Но красиво, быстро и легковесно, не поспоришь. К примеру тот же клиент телеграмма. Но, он не намного быстрее того же Teams от майкрософта на электроне и пофиг что Teams весит в 10 раз больше, главное как выглядит и как работает. И в то же время посмотрите на исходники телеграмма, там же застрелится можно, думаю потратили минимум в 2 раза больше человекочасов чем если бы это был электрон.

Java

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

Что еще можно вспомнить? WinForms от майкрософта — как и делфи — энтерпрайзное говно, плюс только винда. WPF от майкрософта — крутая идея, красиво, но тормозное, только винда и сам майкрософт его лет 7 как закинул.

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

А есть примеры красивого и быстрого приложения на джаве?

JetBrains стек. Точно красиво, на счет быстро — уже зависит от оперативы, но все же.

Они читеры. Это как Майкрософт запили Visual Studio на WPF, но это совсем не тот WPF доступен всем остальным. Там полно своих контролов, полно кастомизации и переписывания дефолтной логики.

В Visual studio задіяна якась особлива версія WPF? Як дізнався та де можна подивитися? Те що там є елементи керування недоступні в WPF з коробки і написані співробітниками Microsoft це правда.

В основном та же версия, но WPF очень customizable, можешь стандартный контрол изменить до не узнаваемости и в плане внешнего вида и то как он рендерится (на высоком уровне, но, думаю, Майкрософт и на низком уровне влазит используя недокументированное API).

Короче стандартные WPF контролы юзабельные только в небольших проектах. Хочется чего-то большего, скорости, масштабируемости — придется очень много их допиливать. Да WPF это позволяет, но хочется иметь это из коробки.

Доречність використання стандартних елементів керування WPF не залежить від розміру проекту. В набір входять типові представники елементів GUI яких в багатьох випадках цілком достатньо. Хочеться щоб Microsoft постійно його розширювала, але цього не відбвувається і замість них сторонні люди за гроші випускають всілякі нестагдартні штуки (є трохи й безкоштовно). Замість customizable слід було написати customized. WPF саме по собі є customizable.

Що розуміється під масштабуванням я не знаю, але елементи керування в WPF створені з розрахунком на те що їх можна видозмінювати під власні бажання. Стандартний ListBox легко перетворити на таке: i.postimg.cc/...​m2mbyc9d/screenshot-2.png. На відміну від сайтобудування допилюються вони набагато легше ніж те що є, вірніше те чого немає, в HTML в який не те щоб часто вводять нові елементи GUI. Щодо швидкості, то які є конкретні перетензії?

Скоріш за все елементи керування присутні в Visual studio написані без якихось недокументованих API співробітниками Microsoft на тій же версії WPF яку використовують і всі інші. Причина припущень про якісь там приховані API походить від незнання WPF.

Що розуміється під масштабуванням я не знаю, але елементи керування в WPF створені з розрахунком на те що їх можна видозмінювати під власні бажання. Стандартний ListBox легко перетворити на таке: i.postimg.cc/...​m2mbyc9d/screenshot-2.png. На відміну від сайтобудування допилюються вони набагато легше ніж те що є, вірніше те чого немає, в HTML в який не те щоб часто вводять нові елементи GUI. Щодо швидкості, то які є конкретні перетензії?

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

Телеграм не на багато швидший за Тімс? Тімс в чаті на 4 людини в мене друкує символ в полі вводу через 6 секунд після натискання клавіші на клавіатурі.

не в тимсе, а в том, на чем он написан

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

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

как раз про тимс: в наши нелегкие времена пришлось с _этим_ плотно работать...ууух. чтобы не жрал половину ресурсов пришлось отключить GPU акселерацию. любая перетурбация с сетью и все — 100% цпу
и эта байда длится годами на всех платформах

Delphi не здохло. Регулярно виходять нові версії. WPF теж не здохло. HTML сторіночка з анімаціями і JavaScript тормозить набагато, набагато набагато більше ніж WPF. На Delphi написано такі некрасиві, просто таки гидотні програми, як Light Alloy, AIMP, FL studio, TuneUp Utilities etc. C++ гірший ніж JavaScript? Бардак в коді Telegram означає що у всіх програм на Qt таке ж саме? І що саме там не так? Скрипти web-програмістів від цього стають кращими, а HTML і CSS кращим вибором чи що? Мені ліниво шукати приклади красивого і швидкого на Java, але можна поглянути на Android. Зрозуміло шо Android не эталон швидкості, але все ж. Красивенька програма в гидотному material design на WinForms: C#/ Modern Flat UI + Font Awesome Icons, Multicolor, Highlight button, WinForm, ще одна: C# - Designing a Flat desktop Application of a Fast Food Restaurant і ще: VB.NET — Table UI WIP Design — Flat UI Modern Design — Guna.UI Framework | C#, VB.NET. На тому ж GTK можна робити програмки з красивим GUI.

Delphi не здохло

Кто на нем програмит? Сколько разработчиков? Сколько компаний занимаются развитием, разрабатывает библиотеки и тулинг?

WPF теж не здохло.

Когда последний раз был апдейт? Именно что-то существенное а не минорный багфиксинг?

Бардак в коді Telegram означає що у всіх програм на Qt таке ж саме? І що саме там не так?

Вот как раз уверен с архитектурой и кодом там все ок, насколько это возможно. Проблема в синтаксисе и монстрообразности С++ и соответственно QT. Это же не для людей. Даже голый html с javascrit-ом выглядят нормально на этом фоне. А ведь там есть купа надстроек и библиотек существенно упрощающие жизнь.

Красивенька програма в гидотному material design на WinForms:

Кнопочки, текст, картинки это хорошо. А что-то сложнее, динамическое? Списки, выпадающие списки, гриды с возможностью кастомизации айтемов, плавный скролинг?

На Delphi не пишу. Зайшов на їхній сайт, побачив що нові версії виходять, що воно розвивається. Які ще компанії? Delphi володіє одна фірма. Ми ж не живемо в безпрограмному вакуумі в якому крім ОС нічого немає?

Проблема в синтаксисе и монстрообразности С++ и соответственно QT. Это же не для людей. Даже голый html с javascrit-ом выглядят нормально на этом фоне. А ведь там есть купа надстроек и библиотек существенно упрощающие жизнь.

Давайте подивимося на код якого-небудь більш-менш складного сайтику, Slack чи ще чогось що мімікрує під нормальну програму і подивимося наскільки там нормальніше і не монстроузно.

Кнопочки, текст, картинки это хорошо. А что-то сложнее, динамическое? Списки, выпадающие списки, гриды с возможностью кастомизации айтемов, плавный скролинг

Знайшов наприклад Free .NET WinForms UI Controls, User Interface Components for Windows Forms | Nevron. Випадаючого списку немає серед елементів WinForms?

Кто на нем програмит?

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

С++, спасибо, поблевал.
Вывод, нет альтернатив

жаль, нельзя трогать лицо руками

яка один раз написана і запускається скрізь; Pidgin, Cherrytree, Qbittorrent, Netbeans

І виглядає як 💩
Тому й перейшли.

Это вы так говорите пока вам деньги платит. Вот если бы вы деньги платили, то сразу начали бы искать компромиссы в плане качества / скорости разработки / стоимости. И, как не крути, электрон тут выигрывает во многих случаях.

Тут больше вопрос как такое допустили что неподобство javascript, де-факто стало стандартом для разработки мультиплатфорных приложений.

В известном треугольнике средний хомячек определился с выбором: быстро и дешево.

А кто заплатит за долго и не дешево? Правильно, тот же потребитель. Кто-то же должен оплатить разработку, поддержку. Так что либо он платит за гигагерцы и гигабайты, либо он платит за софт. Так уж сложилось что докупить гигагерцов и оперативы сегодня гораздо дешевле и проще, чем мудохаться с C++ и QT.

Дешевле и быстрее — всегда некачественее. Но хомячки любят жрать говно, главное его в блестящий фантик завернуть.

Что в твоем понимание говно? Для меня обязательно софт должен быть:
1. Удобным, функциональным (с нужными функциями а не комбайны всего подряд)
2. Быстрым (а если мобильный клиент то супер быстрым, без лагов в прорисовке, анимации, и реакций на действия пользователя)
3. Красивым
4. Надежным (проблема для QT и С++ так написать надежный софт ну очень сложно)

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

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

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

Ценой каких усилий и за какой период времени? Думаете это просто и дешево обходится разработчикам? Я же не говорю что невозможно, просто на управляемом современном языке этого добиться ГОРАЗДО проще и дешевле.

А ціною яких зусиль HTML, CSS, JavaScript було приведено до нинішнього стану? І скільки зусиль ще буде потрібно? Думаєте це просто і дешево? Скільки часу і сил було витрачено на React, jQuery, Vue, Meteor, Dojo, Angular і інше? А чи просто писати костилі для того щоб з мови для розмітки текстку і убого JavaScript зробити щось схоже на працюючий GUI?

Скільки часу і сил було витрачено на React, jQuery, Vue, Meteor, Dojo, Angular і інше?

давайте пригадаймо .NET 1.1 та Java 1.2
скільки часу минуло?
Дельфі? давайте пригадаймо Turbo Pascal і скільки часу пройшло хоча б до TurboVision

і убого JavaScript зробити щось схоже на працюючий GUI?

але він є, той схожий на працюючий GUI
а такого класного Дельфі — «нема»

З чого можна зробити висновок не про то що воно краще(для такого висновку замало статисчно репрезантивних спостереженнь),
але точно що використання HTML, CSS, JavaScript для GUI не такє вже й катастофічно складніше

а якщо додати той факт что то частенько робить молодь, яка крім HTML, CSS, JavaScript нічого не знає, і навіть освіти технічної не має,
то взагалі дивно слухати стогін про те як же на HTML, CSS, JavaScript складно робити GUI від профі у програмуванні

тобто маємо якусь неадекватну оцінку від тих, хто мав би не дивуватись, а дати пояснення — чому ж на HTML, CSS, та убогому JavaScript зовсім не важко робити GUI, якщо те може зробити юнак до 20ти років

коли досвід заперечує дійсність, то вже не досвід називається...

чому ж на HTML, CSS, та убогому JavaScript зовсім не важко робити GUI, якщо те може зробити юнак до 20ти років

На Delphi зовсім не важко робити GUI, якщо те може зробити юнак до 20ти років.

Посил був в тому що були затрачені великі зусилля для доведення технологій (і написання костилів) призначених для розмітки тексту і не призначених для програм до стану коли програмки на їх основі писати стало більш-менш прийнятно. А ви починаєте про Pascal, Java та .NET.

На Delphi зовсім не важко робити GUI, якщо те може зробити юнак до 20ти років.

ну то хай роблять, хто ж заважає.

Посил був в тому що були затрачені великі зусилля для доведення технологій

а мій посил що на любі технології були витрачені велики зусилля

причому теж, ті технології не найкращі.
хто цікавився, або схемотехник (то я нього вчився) — знає яка потвора у вигляді команд х86 виграла битву
а Java. скільки влито зусиль та грошей в неї, кострубату, примітивну мову на початку.

призначених для розмітки тексту

а Java була призначення для чайників — ембедед

ну то й що?

А ви починаєте про Pascal, Java та .NET.

тому що те ж саме

я пам’ятаю як бухтіли профі проти IDE, бо справжній програміст ...!
а потім бухтіли про кольори синтаксису у IDE — у справжньогоо програміста очі ж вилазять, і відволікають від суті!

і такє інше

кого цікавить те бухтіння :)

світ змінювався і буде змінюватись
а той хто має досвід — той розуміє чому, принаймі має гіпотезу

той хто має не досвід а його імітацію, автоматизм — заперечує наявність самих цих змін

а мій посил що на любі технології були витрачені велики зусилля

І це не є контраргументом. Ви просто захищаєте трештехнології і цим самим кажете що гірше — значить краще.

Ви просто захищаєте трештехнології і

так так, а той хто каже про хвороби — і э їх росповсюджовачем

кажете що гірше — значить краще.

я не знаю про краще та гірше

просто намагаюсь з’ясувати як воно є у дійсності

а потім вже буду щось собі думати про краще чи гірше — та критерії по яких можна встановити що щось краще або гірше

І це не є контраргументом

краще та гірше — тим більш справа смаку, а не аргумент.

Бути швидким і

Сколько ресурсов он при этом жрет — мне пофигу абсолютно.

трішечки суперечать один одному. Виходить що можна оновити комп і все. І ресурси це ж не тільки оперативка.

Цікаво подивитися на список програм якими ти користуєшся і які задовольняють усим цим вимогам. Краса і зручність речі дуже вже субʼєктивні.

На кьюте можно красоту делать — закачаешься

Ну VSСode к примеру. Да-да, знаю он медленнее какого-нибудь саблайма, особенно если работать с огромными файлами, но производительность все-равно норм, не жалуюсь, для моих задач и моего hardware (не самое мощное) — хватает с головой.

По-моему мерзость.

продвинутый редактор, и с хорошими плагинами только под JS, TS, *SS всех диалектов и HTML

для тех кто на них пишет, и к серьезной IDE не пристратился — вполне ок.

Да и на Pythоn было вполне приятно в ней писать.

Более того, что касается HTML/JS/CSS — как ни странно, в обычной Visual Studio с ними работать даже менее удобно, чем в VS Code.

Говорю, как человек, который

а) пересел на VS Code с обычной Visual Studio, которой пользовался, начиная с версии 6.0, и
б) своими руками пробовал фронт-енд разработку в VS 2017.

Вот про C++ ничего не скажу, да. Вполне возможно, поддержка «крестов» в VS Code действительно сделана «постольку-поскольку»; всё-таки, «плюсовики» — совсем не основная целевая аудитория этого продукта.

я PHP плагин ставил, попробовал. тоже явно не целевая аудитория, он почти ничего не умеет.

Ну, Delphi убили себя ценовой политикой давным давно. Хотя, было бы круто, если бы он до сих пор был популярен. Написанные на седьмой делфи поделки у меня до сих пор запускаются без проблем :) И рантаймы по 200мб никакие тянуть за собой не нужно было. Да и фри паскаль не плох был(и есть, не считая того, что больше никому не нужен). Эх...

Qt тоже свою цену имеет и не всем подойдет.

Electron — бесплатно и быстро, а JS разработчиков хоть попой жуй, риски минимальные.

Хотя, было бы круто, если бы он до сих пор был популярен.

Во многих супермакретах на кассе вижу знакомые иконочки на кнопках. Делфи проги живы и работают до сих пор! Потому что решают действительно НУЖНЫЕ задачи бизнеса: кассы, склады, всякий учет и автоматизация. Тут не нужно красиво или модно — нужно просто и надежно. «Уродский» интерфейс и кнопочки по-умолчанию всех устраивают. На кассе не нужны жабаскриптовые виджеты с анимацией.

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

А ещё очень дёшево, посмотрите на ЗП Делфи разработчика

Хоронить Д немного преждевременно, свою нишу он имеет, на галерках об этом не в курсе, но в первом мире вакансий достаточно. Энтерпрайз, да. И те же компонентоделы вроде DevExpress тоже производство не свернули. Проиграли стратегически, ценовая политика только один из факапов. IMO шагом в пропасть было идти окучивать .NET. Что автоматически поставило их на шаг сзади MS (а теперь смотрим ещё и на ценовую политику). Потом повелись на фетиш кросс-платформенной разработки, стало одинаково плохо и глючно на всех платформах (Win32 лучше, но попытки натянуть VCL на мобильнэ — это ж полный пэ).
FP — для студентов :) Lazarus — для студентов-мазохистов :)

FP — для студентов

так а почему в C# втаскивают тайпклассы, паттерн матчинг, в джавку — кейс-классы, во все языки лямбды, в свифт монадический чейнинг, а скальное ZIO и IO используется в проде? Там вроде серъезные дяди с сединой в бороде это всё делают, никак не студенты.

Мне кажется здесь под FP подразумевалось не функциональное программирование, а фри паскаль. :-)

Там вроде серъезные дяди с сединой в бороде

ну вот им и бес в ребро.

Пайк вот без бороды, даже дженерики не дает добавить
www.youtube.com/watch?v=5kj5ApnhPAE

Вот только Пайк изначально создавал язык Go, как раз, для вчерашних студентов :)

ок. тогда:
потому что почему-то профессионалов на тру ЯП и ФЯ — не хватает.
и почему же это, зачем эти студенты?

Ну так потому, что работы гораздо больше, чем профессионалов в труЪ ООП/ФП языках?
И далеко не каждая работа требует всей мощи, заложенной в труЪ ООП / ФП?

Ну так потому, что работы гораздо больше,

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

чем профессионалов в труЪ ООП/ФП языках?

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

даже в советах, признаках синьора значится
«выбирает проектные решения которые будут понятны основной части команды»

И далеко не каждая работа требует всей мощи, заложенной в труЪ ООП / ФП?

ну в-третьих, да, оказывается что «математика не нужна в куче направлений разработки ПО»
причем теоретическая мощь заложенная в ООП / ФП — может оказаться пшиком, а то и привести к провалу проекта, даже в руках профессионала.

как можно встретить «шутки»:
один спроектировал DSL, наваял к нему транслятор, ..., ..,.
а второй написал в лоб код

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

потому что теория и практика — не тождественны

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

На практике нередко вся эта академическая мощь закономерно подпадает под бритву YAGNI

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

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

Да и фри паскаль не плох был(и есть, не считая того, что больше никому не нужен)

сравнивая с современными языками, он откровенно плох.

java и C# не особо современные языки. C# ещё бы куда ни шло, но он тоже сидит на подсосе у более прогрессивных, а java всегда пасла задних. Фортран, С и С++ безнадёжно морально устарели не взирая на то, что «можно контроллировать память», они не хорошие, в них вброшено много бабок и на них дофига всего написано, это единственная причина по которой они актуальны. «Зато быстро» в С и С++ платят ценой убийства понятности и читаемости, и когда доходит до разных микрооптимизаций, они превращаются в протёкшую абстракцию. Вполне можно написать генератор ассемблерных програм на каком-нибуть Coq и писать доказуемо правильные и быстренькие программы, без той эзотерики что в С и С++, просто никто в это бабок вкидывать столько сколько в С не хочет, да и скольким джамшутам ты объяснишь что такое исчисление индуктивных конструкций? То то же большая часть писателей на Coq французы. Языки в которых действительно внедряют какие-то новые разработки в области теории типов и прочего, это в основном Haskell и Dotty. Ни в одном Очередной-Скрипт, Пайсон, кРаби, Цвифт, И-го-го-ланг, Ко-ко-котлин не втаскивали действительно новых и мощных фич, там смотрели «как в хаскеле» или «как в скале» или «как в пейпере» и в меру адекватности разрабов языка впиливали. Что касается того самого C#, они очень лениво втаскивают фичи, и только после того как несколько прогресивных языков их заадоптят. А вот что касается С++, там жуткое воспаление NIH синдрома у комитетчиков, и вместо того чтобы делать «как в пейпере» делают как карта ляжет, что в совокупности с «никогда не ломаем совместимость» и никогда не выбрасываем из языка ничего, делают их этого языка не современный хороший язык, а сборник фич по типу «о, смотрите какую крутую хрень я придумал, тащим в стандарт», что по определению хорошим считатся не может. Ну не должны рядовые гребцы изобретать фичи, изобретение фич это отдельная область деятельности, мало пересекающаяся с неакадемической греблей.

Я как-то недавно читал, что якобы разрабы Coq’a собираются из него сделать язык общего назначения, так что кто знает, может через лет 5-10 народ пожелает, чтобы ему вместо питона и джаваскрипта подавали Coq... :-)

так же быстро, как на Питоне или жабаскрипте

Наверняка не смогут, по той причине, что одновременно быстро делать, быстро работает, соотвествует спецификации — не совместимо. Сейчас перекос в сторону быстро делать, быстро работает, вот и давимся багованым софтом. Быстро делать, соотвествует спецификации, это то что ФП — адепты пытаются протащить в мейнстрим, а ниша Быстро работает, Соответствует спецификации слегка пустует.

Сейчас перекос в сторону быстро делать, быстро работает, вот и давимся багованым софтом

это не сейчас.

вся история развития программирования, средств-технологий разработки, от ЯП, до методологий и инструментов о том
быстрее! еще быстрее! что вы там копаетесь, еще быстрее, на вчера надо было!!

а вот ПО для марсоходов в NASA так и программируют как раньше — медленно, тщательно.
эмбедед же. там сроки другие дают.

Ты издеваешься?

Не, ФПшники и правда верят что ФП станет мейнстримом

Но, вопрос, смогут — ли на этом языке писать миллионы программистов и так же быстро, как на Питоне или жабаскрипте?

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

а ФПшники просто не понимают отличий между наукой и промышленным производством.
или им просто второе неинтересно.

Не, ФПшники и правда верят что ФП станет мейнстримом

 Но дело в том что это медленно но происходит.

Но дело в том что это медленно но происходит.

это я слышу чуть ли не с конца 90ых :)

но вы верьте, да что происходит процесс — математизации программирования, его приближения к computer science, а не начиная с COBOLа, ...

работы же всем будет конечно.
И для R&D или для цеха № 15а

Ну учитывая скалу в проде, лямбды и рекорды в Java, таки успешно.

Ну учитывая скалу в проде

в проде встречаются и более диковинные ЯП

речь же о мейнстриме, и тренде

лямбды

в JS они были сразу.

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

и рекорды в Java

чтобы DTOшки быстрее шлепать, меньше морочиться с гидраторами и рефлексией.
тоже мне, «наука»

тоже мне, «наука»

Как раз таки наука и показала, что абстрактная кантовская вещь себе в виде обьекта не нужна.

Как раз таки наука и показала

докладу
«Почему ООП провалилось?» многовато лет, чтобы цитировать его как адекватное отражение действительности

так можно цитировать что резиновая обувь вреднее лаптей, и скоро все поймут, и на волне движения к эко переобуются в лапти

а то что объекты проникают в ФЯ — вас не смущает?
И ту же Scalу Одерски защищает: она не ФЯ, она мультипарадигменная!!

наука которая не соотстветствует действительности — и является лженаукой.

наука которая не соотстветствует действительности

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

я вас огорочу, но по вашему определению все науки — лженауки.

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

Модель не соотвествует действительности по определению.

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

это я и называю — «недообразованной гуманитарностью» — полное незнание азов, которое компенсируется догматизмом и изобретением на ходу своей философии :)

но глупые определения —

по вашему определению все науки — лженауки

это генерю конечно я :D

другими словами

делать вывод что раз смартфоны гораздо более наукоемкие чем мобилки с монохромными экранами — то пользователи смартфонов стали бОльшими специалистами в изготовлении смартфонов — неверно

а вот то что смартфоны позволяют пользователям выполнять больше разнообразных задач с их помощью чем мобилки — да

но задачи то эти — не стали научными, и не обнаучились.

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

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

так и с мейнстримом в программировании:
С — вечен.
хотя в него добавлено уже столько, с времен его появления...

Но он не станет от этого академическим ФЯ

и сколько в Java не будут добавлять всякого разного, Scalой она не станет
А сама Scalа — никогда не станет мейнстримом.

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

Підписатись на коментарі