Безвозмедно займусь разработкой enterprise-проекта

Я тут подумал, vbr, действительно – может надо порносайт какой-то сделать… Тут нужно только какую-то изюминку так сказать. Чтобы все точно с порнхаба ушли. Потому что по хорошему, там уже за столько лет можно было все уже пересмотреть и все новое наверное стало скучным. Не знаю там, порно для котиков или кам-сайт для песиков. Что-то в таком духе.

На мое адекватное предложение по цене и срокам получил что-то типа «да откуда вы все такие лезете».

Так это нормально :)

Нет. Движок JavaScript просто вхолостую такты процессора жрет - и все.

Шта.

Заморозьте человека, не видите что ли, ему плохо.

это не энтерпрайз. Лучше пусть Ananas реанимирует.

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

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

Отличный план!

Игру сделай :) И выпусти где нить её, как закончит приносить прибыль, реанимируй выпустив под AGPLv3 + CC BY-SA и пусть себе плывёт само куда хочет.

http://thalassa.croco.net/doc

Тут нужно только какую-то изюминку так сказать.

Сделай хостинг с видео, где люди трахаются с линуксом!

Категорий полно — домашнее траханье. В офисе там милфа, терминал и три начальника. Эмбед отдельно, конечно же.

Присоединяйся к команде разработчиков ladybird, если не шутишь.

Kling started working on SerenityOS in 2018 as a therapy project after completing a substance-abuse rehabilitation program.

:D :D :D

Enterprise это про управление и контроль. Поделие Васи со стороны увы тут не катит. Выбор технологий - это часть процесса того самого тырпрайз. Даже если у тебя супер оптимизировано что-то там, никому нет дела. Современный тыпрайз строится по ддд. Свои поделия обычно делают для core domain. Generic покупается. Но я так понимаю ты не предлагаешь коробочного решения.

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

Не, ну а что? Сработало же. Как по мне, уважухха ему за то, что нашёл в себе силы ;)

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

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

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

Не, ну а что? Сработало же. Как по мне, уважухха ему за то, что нашёл в себе силы ;)

Вот да. Я бы просто провел эксперимент среди обсирателей: обдолбал бы их наркотой пару месяцев, а потом предложил бы написать ОС в качестве этакого рехаба. Вот это умора была бы посмотреть кто из них что понаписал бы. А то на ЛОРе писать – не мешки ворочать.

Ты опоздал, давно есть Kernel Video Sharing.

Enterprise это про управление и контроль. Поделие Васи со стороны увы тут не катит.

С этим я даже соглашусь. Поэтому каких-то больших надежд на этот пост возлагать я и не думал. Но дискуссия ведь интересная получилась :)

объясните над чем вы так смеетесь

Прикинь, на стадии разметки диска в установщике офтопика будет предложение зашифровать диск и там крупными буквами - «люди смотрите, это наш добрый меценат qount_25 зделал!»

можешь дальше воевать с прогрессом

Реализация скорее всего будет в виде веб-аппа.

вебня не нужна, предпочитаю нативный софт

кроме AI

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

У энтерпрайза основные бабки тратятся не на сам софт, а на его поддержку, и это не просто так.

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

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

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

Ты забыл упомянуть эту категорию :)

Как ты свое поделие масштабируешь?

С каких пор жабоскрипт на страничке в браузере пользователя требует масштабирования какого-то? Как это должно выглядеть вообще? Что за бред?

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

Чтобы «поддерживать» голый жабоскрипт нужен просто программист который знает JS, DOM, HTML, CSS. Он всегда сможет разобраться что к чему.

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

Голый JS требует только добавления необходимого кода по мере развития проекта. Поделие на фреймворке требует в добавок постоянного переписывания из-за изменений в версиях фреймворка.

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

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

Принцип KISS - это очень прибыльный принцип. Но он совершенно не пригоден для мухлежа. Только и всего. Именно ради мухлежа и плодится вся эта дрянь, в которой тонет современное IT.

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

Выбор технологий, задание вектора развития продуктов это скорее архитектура предприятия. Манагеры управляют людскими ресурсами на основе функциональных требований от бизнеса и не функциональных от архитекторов. Поэтому строить теории заговора о манагерах я бы не стал :)

На эту тему куча сайтов есть уже

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

Догадайся, какой продукт будет более поддерживаемым:

1. Страничка - JS - XHR - JSON - JS - страничка.
2. Страничка - 1Мб фреймворка - JS - 1Мб фреймворка - XHR - JSON - 1Мб фреймворка - JS - 1Мб фреймворка - страничка.

При этом фреймворк постоянно меняется, а то и вовсе заменяется на другой, например потому что поддержка старого дропнута.

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

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

Выбор технологий, задание вектора развития продуктов это скорее архитектура предприятия

Скорее принцип получения прибыли и её перераспределения.

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

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

Vue весит 30 кб, типичная параша на jQuery как в том старом, добром вебе образца 2008-го 1 мегабайт. Какие у тебя еще там причины насиловать труп поделия резига или на чем ты там карусели делаешь?

А если компания продуктовая? Кто у кого деньги там перераспределяет? Что если компания еще и прибыль имеет?:) Что если в другой вселенной на голом js писать дороже, чем взяв тот же react, vue?

Если ты в рамках троллинга это пишешь, ну может быть смешном. Если ты это серьезно то тут 2 варианта:

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

Vue весит 30 кб

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

типичная параша на jQuery

Ничего кроме параши на jQuery и не получится. Так же как и на вуях-ангулярах-реактах и прочей абсолютно не нужной пакости.

Ты понимаешь что и JS и DOM с которым оно взаимодействует это уже максимально полноценные абстракции? Уже некуда больше абстрагироваться, любая дополнительная абстракция будет делать только хуже.

а удовлетворяющего перечисленным мной двум критериям - ни одного нет

ну скорее я бы рекомендовал сменить род деятельности.

Бгг. :) Вот никак нельзя чтобы в вебню даже иногда заглядывали люди которые могут не напрягаясь и не платя толпе вебмакак написать вебню которая меньше, быстрее и проще чем всё что вебмакаки когда-либо делали. :) Поэтому и реакция такая - «вали отседа, ты чо тут нам малину портишь!». :)

Что до смены рода деятельности - на что угодно могу поспорить, что если ты вдруг купишь мой энтерпрайз, то у тебя через месяц у тебя все клиенты разбегутся, ибо тебе срочно понадобится рефакторинг, CD/CI, фреймворки, масштабирование и прочая не имеющая никакого смысла и надобности шняга. :)

Клованы, блин.

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

зачастую «новым» объявляется даже не хорошо забытое старое, а просто «велосипеды»

кстати, до появления js и css уже была поддержка скриптов и стилей в браузере https://en.wikipedia.org/wiki/ViolaWWW

Фреймворки добавляют в JS модель реактивности, которой у чистого JS из коробки нет. DOM заворачивают в компоненты, потому что innerHTML очень тяжёлый, а кучу createElement поддерживать неудобно. Web components могут помочь с инкапсуляцией, но имена компонентов остаются глобальными, что легко может вызвать коллизии на больших проектах, а механизм слотов недостаточно мощный для удобной композиции компонентов.

Итого основные причины использования фреймворков:

• модель реактивности;
• инкапсуляция компонентов;
• эффективная работа с DOM;
• модуляризация приложения.

Вот ща прям как будто презентацию отдела искусственных проблем для совета директоров прослушал. :)

Вы что, вообще не отдупляете насколько ваши прогоны смешны и клишированы для нормального человека? :) :) :)

Покажите ваш код.

для нормального человека

LINUX.ORG.RU

никаких реактов и им подобных тормознутых фреймворков

Дальше можно не читать эту шиз-клоунаду.

Покажите ваш код.

Бугагашечка. :) Оно прям на ЛОРе валяется. :)

Очень характерно для вебмакак, кстати - неспособность найти даже то, что находится прямо перед носом. :) Поэтому и нужны им вечно какие-то фреймворки с курсами и видосиками. :)

То есть не покажете. Было предсказуемо - слишком много пустых слов.

Невероятная тупость. :) Типичный пользователь вуя с реактами, ангулярами и пр. Это же просто праздник какой-то! :)

голый жабоскрипт всегда проще каких-то поделий на фреймворках

Отсутствие фреймворка оначает лишь, что тебе придётся песать его самому. Кривой, бажный, недокументированный и с нулём ответов на стековерфлоу. Зато у каждой команды свой %)

Кстати, реакт — это библиотека, а не фреймворк. Делает одну вещь — view = f(state), тебе остаётся только написать f (ну и доставить state, конечно).

Голый JS требует только добавления необходимого кода по мере развития проекта

Читаем между строк: на голом JS любой проект слегка крупнее курсовой работы стремительно катится в неподдерживаемое write-only говнище %)

50 оттенков работы с DOM и прочие шедевры в жанре эротического хоррора.

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

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

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

Ты понимаешь что и JS и DOM с которым оно взаимодействует это уже максимально полноценные абстракции? Уже некуда больше абстрагироваться, любая дополнительная абстракция будет делать только хуже.

В DOM нет ни реактивности, ни декларативности. Также нет поддержки шаблонов.

DOM это исключительно императивное API с событийным подходом. Максимально примитивный подход к построению API.

Собственно львиная доля фреймворков реализуют что-то из этого. Без этих технологий писать приложения неудобно.

Интересно посмотреть на фреймворк m-html. Он немного показывает то, каким мог бы быть HTML и соответствующее API, если бы его проектировали не в лоб.

Ну вот например его убийца Графаны на Ванилле Вебные аналого-цифровые индикаторы.

Я даже не удивлен.

В DOM нет … декларативности

Ээ? HTML вообще-то и есть декларативное описание DOM.

Также нет поддержки шаблонов.

Custom elements. Там даже элемент <template> есть.

Но ведь ты ничего не умеешь. Хочешь сделать хорошо, сделай дистр который не тормозит.

HTML вообще-то и есть декларативное описание DOM

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

Custom elements. Там даже элемент <template> есть.

Custom elements так-то могли быть неплохи, но их снова толком не доделали. Элемент <template> как шаблонизатор не работает, он просто будет хранить предварительно распарсенное поддерево DOM. Чтобы подставить в него значения, придётся вручную найти нужные элементы и присвоить им те или иные атрибуты или содержимое. Из элементов шаблонизации только слоты есть в которые данные из родительского элемента не пробросить. Итерации элементов тоже нет, а без этого с динамическими списками и таблицами работать тоже неудобно. Да, минимальная инкапсуляция DOM и стилей появилась, но, опять-таки, айдишники глобальные, имена кастомных элементов глобальные — привет неожиданным коллизиям.

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