Я в этом вижу + т.к. поддерживается именно дисциплина написания кода, ведь ты должен учитывать разные поведения. А баг, выявляемый спустя 30 лет работы бывает в любом языке.
Ожидаешь получить это, а не получаешь ничего.
И всё-таки видимо проблема именно в перехвате и не пробросе дальше ошибки. Я в чистую пишу и мне всего хватает.
Проблема в количестве особенностей. И в том как это вообще все пишется и реализуется. Первый по этому фактору конечно же perl, затем идет js со своим ворохом проблем.
И опять таки у всех свои проблемы и это надо оценивать в рамках конкретной задачи, а не глобально ибо так глобально все косячные одинаково. Нет более косячного.
Ну и так ещё, еслиб JS был прям такой косячный он бы так не взлетел.
С фреймворками заметно проще все же. Особенно когда SPA пишешь.
Не спорю, но иногда они вносят огромный оверхед. Проще тогда использовать ES Modules и Custom Elements + они нативные для браузера, а значит реализация низкоуровневая и более быстрая.
Есть похожий язык lua и он все же попрямее и предсказуемее работает.
Lua опять таки не для всех задач подойдёт, для веба был бы тяжеловат и пришлось бы делать больше костылей. Я на Lua писал. Против аргумента ничего не имею, но в рамках веба не пошло бы.
Не ломает. Он точно так же вставляется как картинка и не управляет остальным контентом.
Медиа за исключением картинок это уже не про документы, а я зацепился именно за аргумент против html+js, что это уже не документ.
Что значит не управляет, контентом в рамках области своей управляет, да не HTML, однако восприятие у пользователя от странички в целом. А потом ещё и использует внезапно устройства по типу микрофона и камеры.
Проблема как раз в js. Он при этом ничего не пишет в логи.
Проблема не в JS, а в коде, который вы написали. Про логи — он выбрасывает ошибки, а если вы сами где-то перехватили и не вывели в консоль, вновь вы сами виноваты (возможно это особенность фреймворка, но опять таки не языка).
Плюс местами реализация откровенно имеет «особенности» и я такого количества особенностей в других языках что-то не наблюдал.
Особенности есть везде, даже в C++, например когда класс реализует пустую, нечего не делающую перегрузку просто по тому, что такое соглашение на потоки и у потоков должна быть именно эта перегрузка.
В куче динамических языков нет того маразма что есть в JS. Так что тут проблема не в компиляторе.
JS вообще много назначений сменил, одно из главных заблуждений, что он сделан для браузеров был т.к. первое применение было именно серверным. А потом просто вытеснил другие языки, естественным отбором.
Количество бойлерплейта который сейчас приходится писать мне не нравится. Причем это я еще использую тот фреймворк который позволяет писать меньше.
Сделайте свою базу для проектов. А потом почему обязательно обращаться к бойлерплейтам, ведь они могут не подойти для вашего конкретного случая.
С фреймворками так же, зачем использовать обязательно фреймворки?
Я писал на куче других языков. И только в js такая куча идиотизма и наслоений наблюдается. И как раз из-за изначально плохого дизайна, а затем из-за той самой совместимости которая сейчас мешает выкинуть плохие части.
Я тоже достаточно языков перепробовал, но JS был один из первых и знаете, мне как-то проще. По поводу дизайна языка я ещё не встретил ни один идеальный по дизайну ЯП. У всех свои проблемы. Даже повсеместно сейчас внедряемый TypeScript имеет свои косяки в т.ч. идеологические. В итоге я вернулся к чистому ECMAScript 2020.
В случае js как раз пытаются. Что-то писать на js без фреймворка сейчас весьма странное занятие. И слой фреймворка что-то толстоват.
Слой фреймворка действительно толстоват, но это по тому, что фреймворки пытаются делать всё сразу, чтобы их использовали больше. А писать без фреймворков отнюдь не странное дело. Последнее время я так и делаю и знаете получается сильно быстрее и меньше по размеру, чем с фреймворками. Использую только нативные возможности ECMAScript и Web API.
Если нет поддержки, то язык транслируется в js. Как бы смысла маловато. Хотя конечно в планах попробовать тот же ts есть.
Попробуйте реализовать какую-то фичу. Да допустим она будет доступна только там, где будет WebAssembly. Однако пока вы реализуете и начнёте применять WebAssembly уже будет у весомого числа клиентов.
Нет. Тут есть разница. flash был отдельным элементом документа со своим отдельным идентификатором, как сейчас к примеру видео или звук. Это просто элемент.
И он не модифицировал документ.
И всё-таки если говорить тогда о назначении документа, он так же как и видео/аудио ломает концепцию текстового документа. Пришли к той же проблеме, что кидалась в сторону JS.
И со старыми косяками и «особенностями». Такое себе. Плюс новые фичи иногда добавляют так что лучше бы не добавляли.
Тут хотя бы новые фичи добавляют именно для пробы и делают непосредственно частью платформы после тестов и применений в живую. Те же Observable убрали в пользу Proxy.
Вполне дается. Просто в отличии от кучи других языков приходится помнить про 100500 ограничений и всякого маразма который довольно сильно мешает жить.
Зато язык вам даёт шанс выстрелить в ногу, чтобы больше не стрелять в ногу. В других же случаях все эти моменты вы не увидите т.к. статически типизированный компилятор за вас постарался и показал, что вот тут аяяй. С одной стороны хорошо, а с другой стороны вы перестаёте именно разбираться в языке в его тонкостях т.к. за вас это сделает компилятор.
Знаете программисты конечно любят автоматизировать рутину, но какой-то процент рутины должен оставаться иначе программист потеряет свои навыки за неиспользованием.
А плохого много есть и в других языках и хорошо, что в с этим не столкнулись. Язык программирования это инструмент, а у каждого инструмента есть свои плюсы и минусы. Вы же разводным ключом не пытаетесь резать хлеб, или ломом переворачивать яичницу.
Я просто спокойно дождусь повсеместного внедрения webassembly и перекачусь на другой язык.
Я не против WebAssembly даже только за, НО и там найдётся свои недостатки уж поверьте.
А по поводу внедрения, что мешает начать сейчас? Ведь браузеры уже поддерживают WebAssembly и довольно таки давно.
Мы бы банально не пытались лепить из документа приложение.
Как это не пытались? А само существование флеша это разве не та самая попытка? Вы ведь всё-равно флеш встраиваете в HTML, так же как и JS.
Да куда хуже чем сейчас то? Ну и под jvm внезапно есть не только компилятор java, а куча еще других языков в том числе и не статически типизированных. А это позволяет спокойно развивать и измерять язык. Что сейчас весьма сложно делать в js из-за как раз обратной совместимости.
Ой, поверьте хуже можно сделать всегда, даже когда кажется, что хуже некуда. Как раз таки сделать плохо сильно легче чем сделать хорошо.
Под JVM есть язык для математиков Matlab, вот только он падает завидной частотой, ясно дело что это зависит от условий, однако другие почему-то в этих условиях и стеме же задачами (например Python) не падают.
А мне эта самая обратная совместимость JS ооочень нравится это не новый язык каждые 4-8 лет, а всё тот же, просто с новыми фичами. Старый код продолжает работать, его не нужно поддерживать так как нативный.
А что у меня там будет? Вот у меня сервер, для того чтобы браузер запустил оттуда какой-то код, я ему должен его как-то отдать. Если я отдам ему файл с js он его не будет исполнять.
Так JS разве не код? любой другой набор данных не может быть этим кодом? Будет исполнять, если реализовать это в браузере. Вообще если реализовать спецификацию HTTP, а именно заголовки LINK, то вы можете просто отправить text/plain с заголовком LINK на скрипт или ещё лучше. Если браузера сам будет запускать этот код, например как Deno.
Я это отлично знаю, а DOM туда пытаются запихнуть потому что внезапно стало надо рендерить html. Ой и вернулись к нему обратно.
Если не было бы HTML, DOM бы всё-равно был, возможно слегка в ином виде, но был бы т.к. ой внезапно нам всё ещё нужно что-то рендерить иначе какой это браузер (обозреватель)?
Приложение продолжает его эксплуатировать.
По тому, что обратная совместимость.
Ну только вот она начинает постепенно отсыхать.
А я вижу обратную картину, ведь Веб это не одни лишь HTML да JS с CSS. Это в первую очередь Сеть обмена данными, привычный протокол в которой это HTTP, но есть и куча других.
В нативном приложении у меня биндинг на ровном месте не теряет реактивность или не перестает отрисовывать новые добавленные данные в отличии от JS.
Ну началось, может проблема не в JS в вас? В том, что вы не работаете с ним в чистом виде и соответственно не разбираетесь в его природе/сущности и том как он работает?
У меня почему-то если я навесил обработчики событий они исправно срабатывают, если я добавил элементы в дерево, они отображаются.
Вообще всё сошлось, что у вас в целом претензии к JS и к платформе, видимо вам просто она не даётся по этому такое отрицание. ECMAScript за последние года сильно улучшился, а уже веб платформа тем более она стала именно платформой. И к сожалению или к счастью за свою историю веб пришел к тому, чем он сейчас является и получил такую популярность, которая у него есть. Неподходящие идеи отсеиваются, а главная задача это обратная совместимость — не сломать то, что уже есть.
Если современный веб не устраивает (а ввиду обратной совместимости это врят ли изменится) рекомендую начать инициативу по созданию своего стека технологий/браузера. Вот там и посмотрим какая версия выживет в итоге.
Убило его больше не желание adobe открыть технологию.
Не только, моральное устаревание реализации, а т.к. это не часть веба и тем более проприетарно не страшно было отказаться.
А если бы открыли то вполне может быть что мы бы и не имели этого чудного кособокого уродца под названием html+js.
Наличие флеша не избавило бы от html+js или любая другая пара технологий внутри флеша.
Вполне достаточно будет если будет нормальный человеческий доступ к компонентам и нормальная виртуальная машина аля JVM без привязки к кривому и косому js.
А если не будет? А если тем более не JVM? И благо, что не JVM. Java знаете ли тоже не менее кривая и косая (подставьте на место Java любой ЯП).
Который все равно будет html документом иначе браузер не запустит это все на исполнение и при этом создастся DOM.
Не будет HTML кто вам такую чушь сказал вообще? То, что теги просто удобно для отладки и восприятия использовать не значит, что DOM внутри это тэги. DOM это дерево объектов/компонент такое же как и у нативных приложений. А вообще отправляю вас поизучать исходники браузеров хоть Chromium, хоть движок Servo.
Потому что это банально другая среда исполнения.
Если мы отмотаем в самое начало
Node.JS пошел именно из исходников браузера, если точнее это V8 движок и отсутствие компонент отрисовки интерфейсов Layout, DOM, CSSOM, Parser и то туда думают впихнуть DOM обратно. Однако есть проекты по типу Electron, где эти компоненты вернули. Как я сказал убираем HTML Parser и получаете свою мечту.
То проблема именно в том что из первоначального софта предназначенного для просмотра гипертекстовых документов, пытаются слепить среду исполнения приложений.
Это не проблема, а прогресс. HTML это не приложение если мы продолжаем речь о нём. Если уже о браузерах (А EMAIL/FTP клиенты по сути имеют ту же идею, что и Браузеры), то просто в них увидели потенциал именно платформы — распределённой платформы и всё.
А так-как первоначально это было не так и надо сохранять еще заодно возможность просмотра документов, получается так себе.
Веб такой популярный из-за обратной совместимости.
Банальный биндинг полей требует кучи телодвижений прям в браузере.
Построение интерфейса в нативном приложении такой же банальный биндинг параметров кучей телодвижений прям не отходя от кассы.
Можете, убираем необходимость парсинга HTML. На уровне браузера можно просто получить заголовок LINK с сылкой на скрипт так же создать для него окружение с DOM и в этот DOM ничего не писать т.к. не парсим. В Node.JS нет отрисовки, но JS код работает. Оставляем от браузера только компоненты V8 VM, Layout, CSSOM, DOM и готово.
Более того приложения на современных фреймворках продолжат работать ведь они работают не с HTML, а именно с DOM.
Нет там никакого dom. Там есть коллекция компонент которая не имеет никаких xml меток ничего. Нет там никакого xml внутри. Про это я уже раз в четвертый говорю xml после сборки пропадает и вставляются компоненты. Если вам до сих пор это не понятно посмотрите на IoC в java. К примеру в Spring раньше использовали xml для декларативного описания, а сейчас переехали на аннотации.
Object Model есть иначе как вы собрались отрисосывать элементы с иерархией/планом не имея виртуального дерева (описания расположения) этих элементов? Вот эта коллекция компонент и есть Object Model и при желании можно реализовать интерпритацию этой коллекции именно как xml.
В вебе тоже нет ни какого HTML внутри уже после парсинга HTML документа, а есть "коллекция" (точнее древовидная структура) этих виртуальных компонент, которая при желании совершенно спокойно конвертируется в обычный HTML. Отладка представляет в виде HTML, по тому, что так проще для восприятия не более.
Нет. Потому что банально можно открыть инспектор и посмотреть документ. В случае html изменяется именно документ и я могу сделать слепок в в виде статического html и посмотреть его потом. В случае же нативного приложения сделать этого нельзя. Потому что там это коллекции объектов с аттрибутами.
Инспектор отображает не документ, а коллекцию (древовидную структуру) компонентов, в удобном виде, связанном с контекстом т.е. HTML, но внутри это ни разу не HTML. Это сущности/объекты/классы реализующие конкретное принятое поведение этого элемента. CSSOM отвечает за отображение/отрисовку этого дерева.
Слепок в виде статического HTML это сериализация дерева компонент не более. И в случае нативного можно, только там сериализация коллекции компонент не предусмотрена.
Нет не размазывается. На выходе у mvc статический документ, который никак не изменяется. Это может быть не только html страница, так что view на стороне клиента нет, так-как и логики нет.
Серьёзно, ну конечно у нас JS код раньше не было only client side, у нас раньше не было отдельно кода на других языках (PHP/Python for example). По поводу не только HTML да, JSON это тоже VIEW, вот только для пользователя пригодный формат это HTML, и то который в браузере тоже по своему обрабатывается и представляется в другое VIEW. И логику можно на стороне клиента сделать, чем клиент хуже сервера, пусть сам готовит данные для сервера. Это уже к слову тенденция к edge computing (вычисления на границе/другой стороне).
В случае нормальных языков там уже все загружено и закешировано. Как итог занимает заметно меньше времени.
Не всегда и не любой язык, однако инициализация всё-равно требует времени и ресурсов.
Именно по этому я и говорю что использование html+js для создания приложений так себе идея. Более правильно было сделано во флеше. Когда браузер видел что на той стороне есть приложение и запускал его у себя в специальной машине.
Более того весь тренд текущий в том же webassembly опять идет в ту сторону, чтобы грузить бинарный код со стороны сервера и выполнять его у себя. После этого останется еще один шаг оторвать выполнение приложения и его рисовку от DOM html. И в этот момент получим нормальное нативное приложение запускаемое в браузере.
Флэш умер, он дыряв и кучу дыр в безопасности породил, а ещё он был не менее прожорлив, если не более и пихали его в таких количествах. WebAssembly это уже часть веба, Flash же был сторонней технологией, а отрисовку никто не оторвёт от DOM т.к. это Object Model — просто коллекция компонент. И даже в этот момент мы не получим нормальное нативное приложение. Как минимум будет песочница и ограничения даже на любой другой код в WebAssembly
В том то и дело что не играет. В вебе ближайший аналог того как это работает в андроиде и других ОС это canvas.
Нет, по секрету скажу, что даже HTML отрисовывается в Canvas уровня приложения это то же view, что и при использовании XML и другого механизма OM (дерева объектов), к которому вам не дают доступ, как в случае веба через DevTools и в представлении HTML, чтобы вам как человеку было проще ориентироваться в этом графе.
могу создать точно такой же интерфейс и без xml деклараций. К примеру если мне надо динамически генерить чекбоксы, они не прописываются в xml, а прям из кода вставяются.
Можете, но делаете это вы на аналогичном *OM API, я так же могу не прописывая HTML собрать такое же представление используя только DOM API и выше я привёл примеры и даже с XML и просто текстом.
DOM работает без HTML, откуда вы взяли, что он без него не работает. При загрузке страницы HTML используется браузером только на начальном этапе, чтобы перевести структуру HTML в дерево виртуальных объектов (DOM). А дальше уже работа именно с виртуальным деревом, а не файлом/текстом как таковым. То, что вы можете в DevTools посмотреть это дерево в HTML представлении и выгрузить его так не означает, что внутри это работа с текстом.
Я могу создать документ используя DOM API и собрать там произвольное дерево.
Не меняем. Это свойство объявленного компонента. И в xml лежит первоначальное значение.
Так всё-таки меняем первоначальное значение на новое, внутри это изменение значений конкретного аттрибута xml элемента, да вам как разработчикам нативного приложения это не показывается, как в случае с вебом, НО на низком уровне это такое же дерево элементов, хранящее значения атрибутов, названия тегов, расположение относительно друг друго т.е. DOM. HTML тоже является разметкой ровно до того момента, как браузер его распарсит в DOM дерево. Всё опять таки так же.
Дааа конечно :) Появляется два репозитория с backend и frontend и во времена классического MVC js так широко не использовали. Там обычно вспомогательные функции были максимум. Вида фильтрануть из комбобокса значения и т.п.
Ок, а было бы 3 ибо у нас есть backend (server), frontend (server) и frontend (клиент). Да можно в маленьком и монолитном проекте объединить серверные backend и frontend в один, но в большом мы вынесем логику в backend со своим API и будем уже фронт отрабатывать работая через API с бэком.
А про времена, время не стоит на месте и технологии тоже.
Нет. Потому что в классическом MVC клиенту отдается готовая страница, я ее могу отдельно сохранить на диск и потом посмотреть. Если конечно там нет js который что-то шатает в dom запрашивая при этом данные с сервера. А классическое MVC может работать и с отключенным js.
Нет MVC это про весь стек на одной стороне и Model и View и Controller в случае веба же это всё размазывается географически и на разные машины. И классический MVC это даже не про веб, а про нативные приложения. Именно из-за существования и Сервера и Клиента (Браузера, а браузер это VIEW часть) MVC в вебе возможно только своеобразное.
Конечно, но накладных расходов на рендеринг страницы и инициализацию js это никак не отменяет. SPA отросло в первую очередь из-за увеличения кода js. А дергать каждый раз js или его инициализировать довольно тяжелая задача.
Конечно, а полная работа с формированием страницы тоже имеет эти же накладные расходы на инициализацию "ЯЗЫКА НА СЕРВЕРЕ" и рендеринг HTML документа. Вот только в данном случае есть ещё накладные расходы на сеть + неизбежный рендеринг на клиенте HTML бразузером, когда в SPA убирается рендеринг на сервере и уменьшаются расходы на сеть.
Потом SPA это по сути именно приближение к нативным приложениям, вьюхи и клиентская логика которых лежит именно у клиента, а не где-то на сервере.
Ну и перезапускать любое нативное приложение ради смены экрана было бы так же довольно тяжелой задачей, да что было бы так и есть.
Ну и ещё вкину связывая и с предыдущими вашими комментариями. Когда вы делаете интерфейс приложения без xml вы используете какие-то API для построения интерфейса, а эти API есть аналог DOM в вебе.
Virtual DOM появился ввиду малой производительности DOM, так вот через этот DOM можно менять одно представление другим, причём другое может быть совершенно спокойно лежащим рядом ./about.html к примеру.
И да XML из кода напрямую меняем, например цвет кнопки при нажатии или её состояние. Это и есть такое же изменение XML через код.
Это не желание оптимизировать обработку, а как раз таки получение более отзывчивого интерфейса.
Отзывчивость это клиентская сторона. А оптимизация разработки имеется в виду только одной версии кода. Понимаете нет двух репозиториев к примеру с кодом сервера со своими шаблонами и логикой и отдельно клиентского со своими и логикой. А это заметное ускорение непосредственно разработки и улучшение будущей поддержки кодовой базы — меньше поддерживать.
веб-интерефейс в режиме SPA + REST API для клиента работает заметно быстрее, чем классическое MVC приложение. Менять кусочки в virtual dom быстрее чем рендерить и по новой запускать js на каждый запрос в классическом MVC.
В вебе классический MVC не применим т.к. в отличии от нативных приложений веб-приложение раскидано между разными машинами, которые расположены в разных точках пространства. Model Controller на сервере, на клиенте View Controller. Либо MVC на сервере, но тогда клиенту нужно больше работать с сетью, а сеть не дешевый ресурс на самом деле.
Менять кусочки в virtual dom быстрее чем рендерить и по новой запускать js на каждый запрос в классическом MVC.
Только из-за меньшей работы с сетью, опять таки другой принцип нежели с нативными приложениями, где вьюхи лежат на клиенте только.
Простите, что?
Как структурированные данные вообще в принципе могут быть документом?
Ок, ок если будем придираться, то и HTML не документ ни разу, а лишь язык разметки, так же как и XML: eXtensible Markup Language / HyperText Markup Language. Однако есть ещё объединение XML и HTML в виде XHTML или уже забыли?
Ну пытайтесь. И как, успешно напытались?
Очень. Вы работали в той же Android Studio? И не додумались ли, что layout пишется на XML и именно XML в данном случае играет туже роль, что и HTML в вебе? И что Java/Kotlin играют роль JS в вебе?
И проблем тут нет вообще. Передавайте данные, а не документы.
А уж как пользователь будет представлять эти данные, в виде документов или ещё там чего-то — это вообще его дело.
Отлично, буду передавать пользователю данные в бинарном виде, а он пускай уже сам разбирается, что он хочет и как хочет от этих данных. В крайности не уходите пожалуйста, пользователь хочет иметь удобное представление этих данных. И веб с самого начала есть это удобное представление данных.
И главная проблема всегда и всюду будет тогда, когда кто-то слишком «умный» решает за пользователя, что ему нужно.
Главная проблема, когда "пользователь", даже не использующий конкретное решение решает, как и что нужно пользователям, использующим решение.
Следствие — суть яростное недоверие к пользователю, основанное на крайне странном и абсолютно не понятном убеждении, что пользователь проинтерпретирует данные не верно.
Относительно любой разработки будь то веб, будь то нативные приложения всегда недоверие к пользователю и защита пользователя от него же ("защита от дурака"), ведь пользователь не знает как хранятся и обрабатываются эти данные. Для пользователя это просто чёрный ящик с красивым и удобным фасадом, как и любой интерфейс. И это кстати не непонятное убеждение, а следствие многолетних практик.
Вот пример, у вас большое приложение, например Система мониторинга ЧС ГУ МЧС. И тут какой-нибудь человек вводит данные к примеру в поле даты указывает дату 19 / 12 / 2019, а программа поддерживает только вид 19.12.2019 и разработчики даже и не могли представить, чтоб кто-то разделял дату слешами или использовал другой порядок. Как результат мы получим убидую на полторы недели систему ибо она обрабатывает трафик в режиме реального времени и одна ошибка привела к многократным коллизиям. Да пример притянут, но такие случаи казалось бы невозможные обычно и происходят.
Нет, возможно если вам дать эти данные в бинарном виде и без описаний вы разберётесь, но по себе не судите есть куча народа, хорошо если продвинутые пользователи, но чаще уровень начальный.
П.С.: Определения «документа» вы даже и не найдёте. Имею ввиду того «документа», которые болтаются в сети.
К сожалению в сети болтаются и DOC и DOCX и PDF и JPG и PNG все они могут быть документами, а то, что HTML называют документом так просо сложилось. Markdown же не называют документами, хотя цель и задачи те же, что и у HTML. Ну и в сторону XML тоже документ — как бы тег DOCTYPE именно о типе документа.
Я в этом вижу + т.к. поддерживается именно дисциплина написания кода, ведь ты должен учитывать разные поведения. А баг, выявляемый спустя 30 лет работы бывает в любом языке.
И всё-таки видимо проблема именно в перехвате и не пробросе дальше ошибки. Я в чистую пишу и мне всего хватает.
И опять таки у всех свои проблемы и это надо оценивать в рамках конкретной задачи, а не глобально ибо так глобально все косячные одинаково. Нет более косячного.
Ну и так ещё, еслиб JS был прям такой косячный он бы так не взлетел.
Не спорю, но иногда они вносят огромный оверхед. Проще тогда использовать ES Modules и Custom Elements + они нативные для браузера, а значит реализация низкоуровневая и более быстрая.
Lua опять таки не для всех задач подойдёт, для веба был бы тяжеловат и пришлось бы делать больше костылей. Я на Lua писал. Против аргумента ничего не имею, но в рамках веба не пошло бы.
Медиа за исключением картинок это уже не про документы, а я зацепился именно за аргумент против html+js, что это уже не документ.
Какой же это документ, это уже приложение.
Проблема не в JS, а в коде, который вы написали. Про логи — он выбрасывает ошибки, а если вы сами где-то перехватили и не вывели в консоль, вновь вы сами виноваты (возможно это особенность фреймворка, но опять таки не языка).
Особенности есть везде, даже в C++, например когда класс реализует пустую, нечего не делающую перегрузку просто по тому, что такое соглашение на потоки и у потоков должна быть именно эта перегрузка.
JS вообще много назначений сменил, одно из главных заблуждений, что он сделан для браузеров был т.к. первое применение было именно серверным. А потом просто вытеснил другие языки, естественным отбором.
Сделайте свою базу для проектов. А потом почему обязательно обращаться к бойлерплейтам, ведь они могут не подойти для вашего конкретного случая.
С фреймворками так же, зачем использовать обязательно фреймворки?
Я тоже достаточно языков перепробовал, но JS был один из первых и знаете, мне как-то проще. По поводу дизайна языка я ещё не встретил ни один идеальный по дизайну ЯП. У всех свои проблемы. Даже повсеместно сейчас внедряемый TypeScript имеет свои косяки в т.ч. идеологические. В итоге я вернулся к чистому ECMAScript 2020.
Слой фреймворка действительно толстоват, но это по тому, что фреймворки пытаются делать всё сразу, чтобы их использовали больше. А писать без фреймворков отнюдь не странное дело. Последнее время я так и делаю и знаете получается сильно быстрее и меньше по размеру, чем с фреймворками. Использую только нативные возможности ECMAScript и Web API.
Попробуйте реализовать какую-то фичу. Да допустим она будет доступна только там, где будет WebAssembly. Однако пока вы реализуете и начнёте применять WebAssembly уже будет у весомого числа клиентов.
И всё-таки если говорить тогда о назначении документа, он так же как и видео/аудио ломает концепцию текстового документа. Пришли к той же проблеме, что кидалась в сторону JS.
Тут хотя бы новые фичи добавляют именно для пробы и делают непосредственно частью платформы после тестов и применений в живую. Те же Observable убрали в пользу Proxy.
Зато язык вам даёт шанс выстрелить в ногу, чтобы больше не стрелять в ногу. В других же случаях все эти моменты вы не увидите т.к. статически типизированный компилятор за вас постарался и показал, что вот тут аяяй. С одной стороны хорошо, а с другой стороны вы перестаёте именно разбираться в языке в его тонкостях т.к. за вас это сделает компилятор.
Знаете программисты конечно любят автоматизировать рутину, но какой-то процент рутины должен оставаться иначе программист потеряет свои навыки за неиспользованием.
А плохого много есть и в других языках и хорошо, что в с этим не столкнулись. Язык программирования это инструмент, а у каждого инструмента есть свои плюсы и минусы. Вы же разводным ключом не пытаетесь резать хлеб, или ломом переворачивать яичницу.
Я не против WebAssembly даже только за, НО и там найдётся свои недостатки уж поверьте.
А по поводу внедрения, что мешает начать сейчас? Ведь браузеры уже поддерживают WebAssembly и довольно таки давно.
Как это не пытались? А само существование флеша это разве не та самая попытка? Вы ведь всё-равно флеш встраиваете в HTML, так же как и JS.
Ой, поверьте хуже можно сделать всегда, даже когда кажется, что хуже некуда. Как раз таки сделать плохо сильно легче чем сделать хорошо.
Под JVM есть язык для математиков Matlab, вот только он падает завидной частотой, ясно дело что это зависит от условий, однако другие почему-то в этих условиях и стеме же задачами (например Python) не падают.
А мне эта самая обратная совместимость JS ооочень нравится это не новый язык каждые 4-8 лет, а всё тот же, просто с новыми фичами. Старый код продолжает работать, его не нужно поддерживать так как нативный.
Так JS разве не код? любой другой набор данных не может быть этим кодом? Будет исполнять, если реализовать это в браузере. Вообще если реализовать спецификацию HTTP, а именно заголовки LINK, то вы можете просто отправить text/plain с заголовком LINK на скрипт или ещё лучше. Если браузера сам будет запускать этот код, например как Deno.
Если не было бы HTML, DOM бы всё-равно был, возможно слегка в ином виде, но был бы т.к. ой внезапно нам всё ещё нужно что-то рендерить иначе какой это браузер (обозреватель)?
По тому, что обратная совместимость.
А я вижу обратную картину, ведь Веб это не одни лишь HTML да JS с CSS. Это в первую очередь Сеть обмена данными, привычный протокол в которой это HTTP, но есть и куча других.
Ну началось, может проблема не в JS в вас? В том, что вы не работаете с ним в чистом виде и соответственно не разбираетесь в его природе/сущности и том как он работает?
У меня почему-то если я навесил обработчики событий они исправно срабатывают, если я добавил элементы в дерево, они отображаются.
Вообще всё сошлось, что у вас в целом претензии к JS и к платформе, видимо вам просто она не даётся по этому такое отрицание. ECMAScript за последние года сильно улучшился, а уже веб платформа тем более она стала именно платформой. И к сожалению или к счастью за свою историю веб пришел к тому, чем он сейчас является и получил такую популярность, которая у него есть. Неподходящие идеи отсеиваются, а главная задача это обратная совместимость — не сломать то, что уже есть.
Если современный веб не устраивает (а ввиду обратной совместимости это врят ли изменится) рекомендую начать инициативу по созданию своего стека технологий/браузера. Вот там и посмотрим какая версия выживет в итоге.
Наличие флеша не избавило бы от html+js или любая другая пара технологий внутри флеша.
А если не будет? А если тем более не JVM? И благо, что не JVM. Java знаете ли тоже не менее кривая и косая (подставьте на место Java любой ЯП).
Не будет HTML кто вам такую чушь сказал вообще? То, что теги просто удобно для отладки и восприятия использовать не значит, что DOM внутри это тэги. DOM это дерево объектов/компонент такое же как и у нативных приложений. А вообще отправляю вас поизучать исходники браузеров хоть Chromium, хоть движок Servo.
Node.JS пошел именно из исходников браузера, если точнее это V8 движок и отсутствие компонент отрисовки интерфейсов Layout, DOM, CSSOM, Parser и то туда думают впихнуть DOM обратно. Однако есть проекты по типу Electron, где эти компоненты вернули. Как я сказал убираем HTML Parser и получаете свою мечту.
Это не проблема, а прогресс. HTML это не приложение если мы продолжаем речь о нём. Если уже о браузерах (А EMAIL/FTP клиенты по сути имеют ту же идею, что и Браузеры), то просто в них увидели потенциал именно платформы — распределённой платформы и всё.
Веб такой популярный из-за обратной совместимости.
Можете, убираем необходимость парсинга HTML. На уровне браузера можно просто получить заголовок LINK с сылкой на скрипт так же создать для него окружение с DOM и в этот DOM ничего не писать т.к. не парсим. В Node.JS нет отрисовки, но JS код работает. Оставляем от браузера только компоненты V8 VM, Layout, CSSOM, DOM и готово.
Более того приложения на современных фреймворках продолжат работать ведь они работают не с HTML, а именно с DOM.
Object Model есть иначе как вы собрались отрисосывать элементы с иерархией/планом не имея виртуального дерева (описания расположения) этих элементов? Вот эта коллекция компонент и есть Object Model и при желании можно реализовать интерпритацию этой коллекции именно как xml.
В вебе тоже нет ни какого HTML внутри уже после парсинга HTML документа, а есть "коллекция" (точнее древовидная структура) этих виртуальных компонент, которая при желании совершенно спокойно конвертируется в обычный HTML. Отладка представляет в виде HTML, по тому, что так проще для восприятия не более.
Инспектор отображает не документ, а коллекцию (древовидную структуру) компонентов, в удобном виде, связанном с контекстом т.е. HTML, но внутри это ни разу не HTML. Это сущности/объекты/классы реализующие конкретное принятое поведение этого элемента. CSSOM отвечает за отображение/отрисовку этого дерева.
Слепок в виде статического HTML это сериализация дерева компонент не более. И в случае нативного можно, только там сериализация коллекции компонент не предусмотрена.
Серьёзно, ну конечно у нас JS код раньше не было only client side, у нас раньше не было отдельно кода на других языках (PHP/Python for example). По поводу не только HTML да, JSON это тоже VIEW, вот только для пользователя пригодный формат это HTML, и то который в браузере тоже по своему обрабатывается и представляется в другое VIEW. И логику можно на стороне клиента сделать, чем клиент хуже сервера, пусть сам готовит данные для сервера. Это уже к слову тенденция к edge computing (вычисления на границе/другой стороне).
Флэш умер, он дыряв и кучу дыр в безопасности породил, а ещё он был не менее прожорлив, если не более и пихали его в таких количествах. WebAssembly это уже часть веба, Flash же был сторонней технологией, а отрисовку никто не оторвёт от DOM т.к. это Object Model — просто коллекция компонент. И даже в этот момент мы не получим нормальное нативное приложение. Как минимум будет песочница и ограничения даже на любой другой код в WebAssembly
Нет, по секрету скажу, что даже HTML отрисовывается в Canvas уровня приложения это то же view, что и при использовании XML и другого механизма OM (дерева объектов), к которому вам не дают доступ, как в случае веба через DevTools и в представлении HTML, чтобы вам как человеку было проще ориентироваться в этом графе.
Можете, но делаете это вы на аналогичном *OM API, я так же могу не прописывая HTML собрать такое же представление используя только DOM API и выше я привёл примеры и даже с XML и просто текстом.
DOM работает без HTML, откуда вы взяли, что он без него не работает. При загрузке страницы HTML используется браузером только на начальном этапе, чтобы перевести структуру HTML в дерево виртуальных объектов (DOM). А дальше уже работа именно с виртуальным деревом, а не файлом/текстом как таковым. То, что вы можете в DevTools посмотреть это дерево в HTML представлении и выгрузить его так не означает, что внутри это работа с текстом.
Я могу создать документ используя DOM API и собрать там произвольное дерево.
И это без HTML только DOM API.
Или вот использую DOM API для построения XML дерева.
Или вот дерево из строк:
Это к тому, что DOM это именно представление в виде дерева объектов. И такие же аналоги деревьев объектов используются и в нативных приложениях.
Так всё-таки меняем первоначальное значение на новое, внутри это изменение значений конкретного аттрибута xml элемента, да вам как разработчикам нативного приложения это не показывается, как в случае с вебом, НО на низком уровне это такое же дерево элементов, хранящее значения атрибутов, названия тегов, расположение относительно друг друго т.е. DOM. HTML тоже является разметкой ровно до того момента, как браузер его распарсит в DOM дерево. Всё опять таки так же.
Ок, а было бы 3 ибо у нас есть backend (server), frontend (server) и frontend (клиент). Да можно в маленьком и монолитном проекте объединить серверные backend и frontend в один, но в большом мы вынесем логику в backend со своим API и будем уже фронт отрабатывать работая через API с бэком.
А про времена, время не стоит на месте и технологии тоже.
Нет MVC это про весь стек на одной стороне и Model и View и Controller в случае веба же это всё размазывается географически и на разные машины. И классический MVC это даже не про веб, а про нативные приложения. Именно из-за существования и Сервера и Клиента (Браузера, а браузер это VIEW часть) MVC в вебе возможно только своеобразное.
Конечно, а полная работа с формированием страницы тоже имеет эти же накладные расходы на инициализацию "ЯЗЫКА НА СЕРВЕРЕ" и рендеринг HTML документа. Вот только в данном случае есть ещё накладные расходы на сеть + неизбежный рендеринг на клиенте HTML бразузером, когда в SPA убирается рендеринг на сервере и уменьшаются расходы на сеть.
Потом SPA это по сути именно приближение к нативным приложениям, вьюхи и клиентская логика которых лежит именно у клиента, а не где-то на сервере.
Ну и перезапускать любое нативное приложение ради смены экрана было бы так же довольно тяжелой задачей, да что было бы так и есть.
Ну и ещё вкину связывая и с предыдущими вашими комментариями. Когда вы делаете интерфейс приложения без xml вы используете какие-то API для построения интерфейса, а эти API есть аналог DOM в вебе.
Virtual DOM появился ввиду малой производительности DOM, так вот через этот DOM можно менять одно представление другим, причём другое может быть совершенно спокойно лежащим рядом ./about.html к примеру.
И да XML из кода напрямую меняем, например цвет кнопки при нажатии или её состояние. Это и есть такое же изменение XML через код.
Отзывчивость это клиентская сторона. А оптимизация разработки имеется в виду только одной версии кода. Понимаете нет двух репозиториев к примеру с кодом сервера со своими шаблонами и логикой и отдельно клиентского со своими и логикой. А это заметное ускорение непосредственно разработки и улучшение будущей поддержки кодовой базы — меньше поддерживать.
В вебе классический MVC не применим т.к. в отличии от нативных приложений веб-приложение раскидано между разными машинами, которые расположены в разных точках пространства. Model Controller на сервере, на клиенте View Controller. Либо MVC на сервере, но тогда клиенту нужно больше работать с сетью, а сеть не дешевый ресурс на самом деле.
Только из-за меньшей работы с сетью, опять таки другой принцип нежели с нативными приложениями, где вьюхи лежат на клиенте только.
Ок, ок если будем придираться, то и HTML не документ ни разу, а лишь язык разметки, так же как и XML: eXtensible Markup Language / HyperText Markup Language. Однако есть ещё объединение XML и HTML в виде XHTML или уже забыли?
Очень. Вы работали в той же Android Studio? И не додумались ли, что layout пишется на XML и именно XML в данном случае играет туже роль, что и HTML в вебе? И что Java/Kotlin играют роль JS в вебе?
Отлично, буду передавать пользователю данные в бинарном виде, а он пускай уже сам разбирается, что он хочет и как хочет от этих данных. В крайности не уходите пожалуйста, пользователь хочет иметь удобное представление этих данных. И веб с самого начала есть это удобное представление данных.
Главная проблема, когда "пользователь", даже не использующий конкретное решение решает, как и что нужно пользователям, использующим решение.
Относительно любой разработки будь то веб, будь то нативные приложения всегда недоверие к пользователю и защита пользователя от него же ("защита от дурака"), ведь пользователь не знает как хранятся и обрабатываются эти данные. Для пользователя это просто чёрный ящик с красивым и удобным фасадом, как и любой интерфейс. И это кстати не непонятное убеждение, а следствие многолетних практик.
Вот пример, у вас большое приложение, например Система мониторинга ЧС ГУ МЧС. И тут какой-нибудь человек вводит данные к примеру в поле даты указывает дату 19 / 12 / 2019, а программа поддерживает только вид 19.12.2019 и разработчики даже и не могли представить, чтоб кто-то разделял дату слешами или использовал другой порядок. Как результат мы получим убидую на полторы недели систему ибо она обрабатывает трафик в режиме реального времени и одна ошибка привела к многократным коллизиям. Да пример притянут, но такие случаи казалось бы невозможные обычно и происходят.
Нет, возможно если вам дать эти данные в бинарном виде и без описаний вы разберётесь, но по себе не судите есть куча народа, хорошо если продвинутые пользователи, но чаще уровень начальный.
К сожалению в сети болтаются и DOC и DOCX и PDF и JPG и PNG все они могут быть документами, а то, что HTML называют документом так просо сложилось. Markdown же не называют документами, хотя цель и задачи те же, что и у HTML. Ну и в сторону XML тоже документ — как бы тег DOCTYPE именно о типе документа.