Свободный (хотябы фактически) и единый стек

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

Вот с этого места подробнее, пожалуйста. Там же обычная Apache License, нет?

Здесь есть спецы, ждём.

Мне интересно, только вот это:

https://stackoverflow.com/questions/52849894/how-to-handle-copyright-notice-in-javascript-bundle

Или что ещё

Что можно сделать с лицензией

Лицензии надо соблюдать. Но в чём твоя проблема я так и не понял. Лицензии есть у почти всего, не мс так от других авторов.

А джаваскрипт выкинь и пиши на норм языке.

Лицензии надо соблюдать

Поспорь с законами природы, ога

А джаваскрипт выкинь и пиши на норм языке.

Чтобы выкинуть жабаскрипт из браузера - нужен компилятор в васм. Не может это в эффективную разработку фронта

Так ты объяснишь в чём проблема то? У любого кода есть автор и, если он только не передал его в общественное достояние, какая-то лицензия с копирайтами.

Права на весь код, на тупоскрипте написанный, переходящие мелкомягким - это не проблема? Океееей

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

Что ангуляр заставляет страдать.

Wasm - это не то, что ты думаешь. Это что-то типа опкодов в питоне или байткода в джаве - представление атомарных операций, которые выполняет интерпретатор за раз. Никто тебе не разрешит ass-семблер запускать… Ну собственно поэтому wasm и сдулся как что-то бесполезное по факту, но позволяющее расширить соевую паству

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

Что мешает использовать Vue и Express на тайпскрипте? Кстати Vue — концептуально более правильный среди «большой тройки» (Vue, Angular, React), и потому, в том числе, работает быстрее.

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

Es ist unmöglich, eine Website in einer Sprache zu schreiben.

Backend:

https://kristaps.bsd.lv/kcgi/

https://www.gnu.org/software/m4/

Frontend: HTML, CSS.

Для бекенда можно ещё PHP использовать.

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

Можно модель данных и апишки типизировать. Тем более, там обратная совместимость, так что для тайпскрипта можно взять и Vue, и React, и Angular, а для джаваскрипта только Vue и React.

Но вуй меньше похож на магазин игрушек чем ангуляр

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

сообщество меньше

Тогда нужно React выбирать. Ведь миллионы мух не могут ошибаться.

писать труднее

И что именно там писать труднее? Наоборот, Vue предлагает наиболее простой, компактный и очевидный код.

В самом начале перед лицензией написано: Copyright (c) Microsoft Corporation.

А в GNU GPL v3 написано Copyright © 2007 Free Software Foundation, Inc. Дальше-то что?

и на фронте и на быке

Обычно это всё равно означает разные валидаторы и структуры и вообще отсутствие шареной логики.

Чойта? А вычислить число Ху? А структуры которые гоняются туда-сюда?

А вычислить число Ху?

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

А структуры которые гоняются туда-сюда?

Потому что придётся заморочиться, сделать монореп с shared-библиотекой, в которой хранить структуры апишки и функции валидации. Далее нужно, чтобы DTO, которыми обмениваются бек и фронт правильно типизировали эти данные и натравливали на них нужные валидаторы. И тут заморочка в том, что сами по себе JSON-объекты, которыми обмениваются фронт и бек, не типизированы. То есть эти DTO в API-слое нужно будет правильно типизировать и валидировать вручную или полуавтоматически.

Например, Nest.js и TypeORM используют class-validator и class-transformer. Там относительно прозрачно (хотя слышал, что class-transformer — довольно капризная штука). Значит нужно будет затащить все DTO в shared, а затем прикрутить обе библиотеки к фронтенду.

Однако есть такая заморочка, что на фронтенде чаще всего будет нужна валидация без отправки на сервер. И вот здесь могут быть трудности с интеграцией этих библиотек с фронтендным фреймворком. Angular использует свою библиотеку для работы с формами и их валидацией (вот как раз, где магазин игрушек выходит боком), а для Vue нужны объекты со своими обсерверами, а не те, которые создаёт class-transformer.

Если же в дополнение к Vue (или React) взять Nuxt.js (Next.js), то всё становится ещё веселее из-за появления дополнительного слоя со своими заморочками.

Права на весь код, на тупоскрипте написанный, переходящие мелкомягким - это не проблема? Океееей

Покажи этот пункт. Если бы так было, никто не писал бы на TS. Ты или просто тормоз или нас читаешь такими. При любых раскладах получается, что ты тормоз или мудак. А с мудаками дела не имеем. Если тормоз, тормози дальше.

Чем он правильнее? Собрались профи, я так гляжу.

Если тормоз - ускоряйся!

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

Чем он правильнее?

Тем, что Vue 3 полноценно использует Proxy, за счёт чего получается чистый и понятный код. Под капотом через прокси-классы реализованы observables и computeds. В результате, простое изменение поля объекта-обсервабла вызывает пересчёт необходимых зависимостей и точечное изменение виртуального DOM, а затем и реального DOM в нужно месте.

Angular и React проектировались до появления проксей, поэтому там обработка событий и пересчёт данных были реализованы через жопу. Хотя им ничего не мешало сделать обсерваблы с интерфейсом в виде функций как в knockout.js. В ангуляре все возможные объекты браузера и элементов обёрнуты в zone.js и rx, что переусложняет и утяжеляет код, но хотя бы сейчас они начали понемногу от этого наследия избавляться, что повысило эффективность и производительность, да и внешне ангуляр стал чуть более походить на вью.

В реакте всё ещё хуже. Там поначалу решили, что можно просто пересчитывать виртуальный DOM, а он быстрый. Оказалось, что это не так. Придумали костыль с shouldComponentUpdate и иммутабельностью объектов. В результате на каждый чих создавались новые иммутабельные объекты и все объекты виртуального DOM, который затем ещё и сравнивался целиком с предыдущей версией. Дальше поняли, что разработчики неосиливают классы и придумали хуки. Теперь на каждый чих стали пересчитываться не только объекты VDOM, но и перевызываться все использованные хуки вместе со своими проверками. Притом сами эти реактовские хуки — функции с лютыми сайд-эффектами под капотом. Вдобавок, увлечение single source of truth в виде redux или подобного хранилища, который передаётся через контекст, вызывает при любом изменении хранилища перерендер всего приложения, из-за чего, фактически, все сложные компоненты по-хорошему нужно мемоизировать.

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

А ты знатно Анону в уши налил.

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

Это ты зря.

что реакт, несмотря на название, — самый медленный и самый нереактивный фреймворк

И это тоже. Библиотечки с фреймворком начали срвнивать.

да и внешне ангуляр стал чуть более походить на вью.

Это…

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

facepalm.jpg

У меня складывается ощущение, что ты совсем далёк от темы разработки с данными инструментами. И Бог бы с ним, только ты же это как «специалист» закатываешь нам! Лучше так не делай.

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

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

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

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

Это ты зря.

Да вот можно почитать даже комментарии на Хабре в статьях про ООП и особенно про реакт при обзоре только появившихся хуков: очень многие твердили, что классы прям сложно и больно, а хуки — чётенько. Так что целевой аудитории классы не зашли.

что реакт, несмотря на название, — самый медленный и самый нереактивный фреймворк

И это тоже. Библиотечки с фреймворком начали срвнивать.

Здесь я подразумевал реакт как связку самого реакта с основными сопровождающими его библиотеками в окружении best practices. С этой позиции вполне себе фреймворк.

У меня складывается ощущение, что ты совсем далёк от темы разработки с данными инструментами.

Поделишься с нами своим опытом?

на фронте пожелания удовлетворять

Не, спасибо, я лучше кодить буду.

GraphQL

Это что ж такое навертеть нужно, чтобы перехотеть вручную параметры запроса разбирать?

в тебе полнейшего нуба вижу я как и в других советчиках… ну смотри. есть у тебя в базе сущности: user, customer, category и product… и вот тебе нужно вывести кастомеров и чтобы с именами юзеров. ты это сделаешь как? ну добавишь в кастомера свойство юзер, будешь его в json сериазовать, а потом потребуется в юзере кастомера возвращать, в продекте список категорий и кастомера, в категории список продуктов, в кастомере список категорий, которые использует… и так на каждый чих ты будешь код менять, и чтобы этого избежать можно graphql применять, который позволяет данные таблиц этих как угодно склеивать, вкладывать, преобразовывать на фронте

читай https://graphql.org/learn/queries/

Здесь я подразумевал реакт как связку самого реакта с основными сопровождающими его библиотеками в окружении best practices. С этой позиции вполне себе фреймворк.

Ты думаешь, Nextjs появился от хорошей жизни? А твоя позиция показывает, что серьёзного ты не писал (или думаешь, что это серьёзно, а на самом деле нет). Когда начнёшь, сразу становится понятно, что такое Angular и почему его используют. И что такое твои «best practices» на практике.

Да вот можно почитать даже комментарии на Хабре в статьях про ООП и особенно про реакт при обзоре только появившихся хуков: очень многие твердили, что классы прям сложно и больно, а хуки — чётенько. Так что целевой аудитории классы не зашли

Если для тебя ООП - это синтаксис…

Поделишься с нами своим опытом?

Фронт открывается нормально тем, кто плотно залезает в мир навёрнутых абстракций и вопроса «почему они появились». Если подвести итог, рекомендую писать на фреймворках и углублённым исследованием паттернов, которые в них применяются. Желательно несколько проектов. Когда осилишь, можно будет глянуть на твои «best practice» в разрезе. И ты поймёшь, в каком говне плавает Front мир. Особенно из-за предоставляемой свободы (React, Vue) и тупизны исполнителей.

Или ты думаешь, что на голом месте MS собрало штат, отвлекло от основной деятельности много умных людей, создало экосистему? Зачем нормальное OOP в мире JS? Зачем строгая типизация? Какие требования были закрыты? Как это повлияло на корпоративный рынок и создание внутренних приложений, которые работают практически на любом устройстве и последние, что я видел, похожи на Lotus от синих по масштабности?

Шизофазия какая-то. Праздники прошли, бросай пить

Кек, определился с гражданской позицией. Веппацк так настраивается, что из ангуляра и из гнезда на выходе получаются два жирных блоба, внутри принципиальная каша. Где были лицензии? Нет никаких лицензий, ничего не знаю. ТюпеОРМ - вещь, Секуелизе не нужен

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

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

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

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

Если выбрать жабаскрипт, то стек выходит такой:

Vue Express + Sequelize

Если выбрать тупоскрипт, то такой:

Angular NestJS + TypeORM (Sequelize для тупоскрипта всё ещё бета)

Сломай систему, останови поток г...а! используй Clojure.

;; Code snippet to show interaction with JavaScript
(ns my-app.core
  (:require [clojure.browser.dom :as dom]))

(dom/appendChild (dom/getElement "body") (dom/create-element "div"))

Это надо на Непале всю жизнь прожить

А чем это от разных react отличается?

можно посмотреть в сторону Vaadin/Jmix и тогда будет везде жаба/котлен, по крайней мере на прикладном уровне. И все это без порнографии типа нестандартизированных текучих фимозных жс рендерилок на фронте или однопотоковой уродливой архитектуры на беке. Хотя лично мне кажется, что оптимальнее на это не заморачиваться и использовать веб-компоненты и порталы, но раз «заказчик требует»..

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

Морда задаётся на быке, не в понятиях фронта

фронт en masse такая сфера, в которой мало общих понятий. Рякт не совместим даже с самим собой(другого разлива) например.

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

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