• Let vs const — что использовать?
    0

    Я немного обобщу, в общем и целом проблемы в выборе let и const нет, минус названный вами в сторону const вами же отображен и на let. Описанный подход prefer-const и вами prefer-let по своей сути идентичны +- (просто инверсия). 99.9% замена const на let ничего не ломает и эти же проценты переиспользование let тоже, однако всегда есть 0.1% когда это приводит к багам.


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


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

  • Let vs const — что использовать?
    0

    Случайный дубль комента по двойному клику. Хабр стоит переводить кнопку в disabled по первому клику.

  • Let vs const — что использовать?
    0
    Сравните с вариантом, когда у вас одно объявление и — внезапно — нужен let. Вроде же по-русски писал, одно с другим связать не можете?

    Вы лучше сразу пример приведите, как я просил с самого начала. Если у вас одно объявление и внезапно понадобился let, сделайте новое в чём проблема?


    Речь не о можно, а том, что в случае const нельзя иначе. Вы вообще обдумываете свои решения или идёте на поводу толпы?

    Речь именно о можно и нужно. В случае с const можно иначе и это let. Вот серьёзно в каком месте не понятно моё краткое объяснение правила prefer-const? "Если вы не меняете ссылку на значение — const иначе let". Где явно случай с вашим тернарным const лучше реализовать через let и с нормальными if. Это правило обращаю внимание не противоречит тому, что вы "пытаетесь донести" не вникнув в то, что я вам писал изначально. Вот для начала сами по обдумывайте то о чём говорит собеседник.


    В первую очередь вы не обдумываете свои решения и ответы, особенно когда пишите про "идёте на поводу толпы". Какой нафиг толпы? Я опробовал prefer-const подход, он показал свои плюсы, я использую его.


    И уж тем более я не "иду на поводу толпы" т.к. эта самая толпа категорически против приватных полей у классов в JS с текущим синтаксисом #fieldName. Я же в этом синтаксисе вижу плюсы: 1. хард приватность, а не "соглашение о приватности", нарушается постоянно; 2. сразу синтаксис показывает, что это приватное поле и не нужно вносить опять таки "соглашение по именованию приватных полей". Тут всё принёс язык и это хорошо.


    Просто? Разговор с того и начался, что prefer-const не даст вам просто поменять, потому что при деструктуризации останутся незименные переменные.

    Просто и про останутся неизменные переменные, ну и пускай останутся. Чем это мешает вам? Вот серьёзно это такая придирка ну серьёзно с натяжкой. Я просто вынесу из const необходимую/мые переменные в let и всё, если это одна, то можно вообще даже в let не пихать если задуматься.


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

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


    Впрочем, вы даже на русском неаккуратно пишите.

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


    P.S. Вдобавок, ниже уже привели ссылки на статьи, почему const не работает. Как верно подмечено, prefer-const заставляет использовать const, когда так совпало, что переменная не изменяется, а не только когда она реально должна быть константой.

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


    Ну и теперь я пишу, что вы идёте на поводу у толпы, которая категорически не приемлет использование const в тех ситуациях, для которых и разрабатывалось это ключевое слово. Даже в proposal на эту фичу были примеры из ряда prefer-const, однако опять таки никто не читает документацию, и следует правилу "в других же языках так, значит и тут так и по другому не может быть".


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

  • Let vs const — что использовать?
    +1

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


    В случае JS все переменные являются ссылками, даже на примитивы т.к. JS унаследовал у другого языка правило, что любое значение это объект, даже сам объект. Соответственно ключевое слово влияет только на эту ссылку, но никак не на значение (объект)

  • Let vs const — что использовать?
    –1

    Возможно вы немного промахнулись и писали Aingis. Я же совершенно как и вы использую prefer-const.

  • Let vs const — что использовать?
    0
    А теперь сделайте имена реально длины и вложенности (settings.product.someParams) и добавьте ещё пару переменных, и вместо искусственного примера сразу увидите раздутие.

    Хорошо, вот тот же отрывок с "реальной длинной":


    const { width, title } = settings.product.someParams
    let { height, aspect } = settings.product.someParams

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


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

    Это уже аргумент с натяжкой т.к. эти же тернарки можно писать и в let и в var. Это уже зависит от разработчика и его желаний сократить код. А вообще это вопрос умения применять тернарки, если правильно оформлять, то и вложенные не будет особых трудностей читать. И да конечно же везде, где можно обойтись без тернарок или сложность условий велика лучше и нужно использовать if.


    Вообще исходный код должен быть читаемым, а то, что пойдёт в продукт уже будет обработано каким-нибудь Terser'ом.


    Что значит «нежелательных»?

    То и значит. Иногда сломать весь код можно и банальным случайным или намеренным изменением значения переменной. К примеру, вот ожидаете объект и выполняете запрос к полю foo.bar, а выше какой-нибудь "Вася" в каком-нибудь if'е на каком-нибудь условии без церемоний записал в ваш let foo значение null. По логике "Васи" всё верно т.к. foo в конечном итоге возвращается из функции.


    Вы либо меняете, либо нет. Не знаете что пишете?

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


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

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


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

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

  • Let vs const — что использовать?
    +1

    Почему?


    const options = {
        width: 100,
        height: 200
    }
    
    const { width } = options
    let { height } = options
    height += width / 16 * 9
    options.height = height

    А вообще ключевое, всё-таки если вам надо менять ссылку на значение в переменной, делайте её let иначе const. Это и есть всё правило.


    const options = {
        width: 100,
        height: 200
    }
    
    const { width } = options
    let { height } = options
    height += width / 16 * 9
    options = { ...options, height }

    Но не проще ли в подобном случае сразу делать так:


    const options = {
        width: 100,
        height: 200
    }
    
    options.height += options.width / 16 * 9

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


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


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


    Относительно последнего абзаца я кстати пробовал и TypeScript и Flow, а в итоге вернулся к чистому ECMAScript с документацией в комментариях по типу JSDoc/ESDoc. VSCode совершенно спокойно распознаёт эти комментарии и выдаёт всё те же подсказки по типам, что и с TypeScript. И в данной ситуации не требуется компилировать в JS/ES и нет проблем с идеологией как у TypeScript (в частности по приватным полям).

  • Let vs const — что использовать?
    +2

    Сравниваете не сравниваемое, если в const из ECMAScript хранить примитивы (которые по своей природе immutable), так же как вы это делаете в других языках с приведёнными величинами (G, PI, e, etc.), то отличий никаких эти константы полностью иммутабельны т.к. ссылка на них иммутабельна и значения-примитивы тоже иммутабельны.


    Если же вы храните в const объект (мутабельный по умолчанию), то и получаете иммутабельную ссылку на мутабельный объект. Чтобы объект был иммутабельным нужно его залочить Object.freeze() (блокирует конкретный объект).


    const immutableObject = Object.freeze({
        name: 'Alice',
        age: 25,
    })

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


    Главное понимать, что var, let, const это всё переменные, которые в сущности являются просто ссылками на значения, соответственно ключевое слово влияет только на область видимости и мутабельность этой самой ссылки, но никак не значения.

  • Let vs const — что использовать?
    +2

    Самое правильное с моей точки зрения это правило prefer-const из eslint. Кратко и просто: Если переменную не перезаписываем, то const. Иначе let. Больше никаких рассуждений не нужно.


    function processItems(id) {
       const items = fetchItems(id);
       for(const item of items) {
            doSomething(item)
       }
    }

    В данном случае обе переменные const т.к. мы их не меняем (изменение атрибута переменной item не относится к изменению переменной).


    Если мы меняем хранимое значение, то let:


    let counter = 0
    counter++
    
    const object = {
        name: 'Bob'
    }
    object.name = 'Alice'
  • Грета Тунберг права? Самолеты VS поезда
    +1

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

  • Новая эра веб-разработки или «всё уже есть»
    0
    Как только WebAssembly как-то взлетит клей в виде JS уберут.

    Единственная такая перспектива, это встраивание WebAssembly как ES Module. Не более.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Это вот как раз в тему что надо сделать поддержку не только отображения документов, но и приложений. В этом случае просмотр документов отдельно, запуск приложения отдельно. К чему в случае с webassembly и идем.

    В случае с WebAssembly отображение будет либо через DOM API, что так же как и с JS. Либо отрисовка в Canvas, что опять таки так же как в JS. В любом случае WebAssembly вклеивается посредством JS.


    А ещё так для информации есть инициатива у Google, Mozilla и Apple сделать бинарный формат JS. Т.е. будешь компилить, а на клиент будет прилетать уже готовый код такого же формата, что и для WebAssembly по сути.

  • Новая эра веб-разработки или «всё уже есть»
    0
    А флеш как-то изменял при этом документ? Насколько я помню нет. И его отсутствие только ломало возможность пользоваться функциями встроенного приложения и все.

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

  • Новая эра веб-разработки или «всё уже есть»
    0
    Эммм что? Размер интерпретатора lua-5.1 у меня в системе 25 килобайт. Вместе с компилятором 200 килобайт. Бинарник nodejs весит 1.1 мегабайт. Его наоборот всюду тащат поскольку он легкий и хорошо встраивается.

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


    Ну и ещё момент, стандарт ECMAScript это именно встраиваемый язык как и lua, JS реализует именно ECMAScript.


    Только вот NodeJS с собой тащит ещё много всякого своего, там работы с операционкой, файлами, CommonJS модули. Всё это добавляет вес. V8 в чистом виде более лёгкий.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Документ. Мультимедийный документ. Это касается только вставки видео и аудио контента, который проигрывается. Если же там входящий поток с камеры или там микрофон это уже приложение. И вот это конечно стоило бы выделить из документов. Про что собственно и речь.

    Отлично, а макросы в MS Word или Excel это что? По моему макросы это как раз язык программирования и никак не вставки видео/аудио, однако это всё-ещё документы. Про потоки с камеры/микрофона, так вот во флеше я видел кучу ситуаций когда делали именно так в вебе. И в такой ситуации флеш ничем не отличается от того, что имеем сейчас.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Просто если язык это позволяет, это ну такое.

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


    Ожидаешь получить это, а не получаешь ничего.

    И всё-таки видимо проблема именно в перехвате и не пробросе дальше ошибки. Я в чистую пишу и мне всего хватает.


    Проблема в количестве особенностей. И в том как это вообще все пишется и реализуется. Первый по этому фактору конечно же perl, затем идет js со своим ворохом проблем.

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


    Ну и так ещё, еслиб JS был прям такой косячный он бы так не взлетел.

  • Новая эра веб-разработки или «всё уже есть»
    0
    С фреймворками заметно проще все же. Особенно когда SPA пишешь.

    Не спорю, но иногда они вносят огромный оверхед. Проще тогда использовать ES Modules и Custom Elements + они нативные для браузера, а значит реализация низкоуровневая и более быстрая.


    Есть похожий язык lua и он все же попрямее и предсказуемее работает.

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

  • Новая эра веб-разработки или «всё уже есть»
    0
    Не ломает. Он точно так же вставляется как картинка и не управляет остальным контентом.

    Медиа за исключением картинок это уже не про документы, а я зацепился именно за аргумент против html+js, что это уже не документ.


    • Что значит не управляет, контентом в рамках области своей управляет, да не HTML, однако восприятие у пользователя от странички в целом. А потом ещё и использует внезапно устройства по типу микрофона и камеры.

    Какой же это документ, это уже приложение.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Проблема как раз в js. Он при этом ничего не пишет в логи.

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


    Плюс местами реализация откровенно имеет «особенности» и я такого количества особенностей в других языках что-то не наблюдал.

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

  • Новая эра веб-разработки или «всё уже есть»
    0
    В куче динамических языков нет того маразма что есть в JS. Так что тут проблема не в компиляторе.

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


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

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


    С фреймворками так же, зачем использовать обязательно фреймворки?


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

    Я тоже достаточно языков перепробовал, но JS был один из первых и знаете, мне как-то проще. По поводу дизайна языка я ещё не встретил ни один идеальный по дизайну ЯП. У всех свои проблемы. Даже повсеместно сейчас внедряемый TypeScript имеет свои косяки в т.ч. идеологические. В итоге я вернулся к чистому ECMAScript 2020.


    В случае js как раз пытаются. Что-то писать на js без фреймворка сейчас весьма странное занятие. И слой фреймворка что-то толстоват.

    Слой фреймворка действительно толстоват, но это по тому, что фреймворки пытаются делать всё сразу, чтобы их использовали больше. А писать без фреймворков отнюдь не странное дело. Последнее время я так и делаю и знаете получается сильно быстрее и меньше по размеру, чем с фреймворками. Использую только нативные возможности ECMAScript и Web API.


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

    Попробуйте реализовать какую-то фичу. Да допустим она будет доступна только там, где будет WebAssembly. Однако пока вы реализуете и начнёте применять WebAssembly уже будет у весомого числа клиентов.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Нет. Тут есть разница. flash был отдельным элементом документа со своим отдельным идентификатором, как сейчас к примеру видео или звук. Это просто элемент.
    И он не модифицировал документ.

    И всё-таки если говорить тогда о назначении документа, он так же как и видео/аудио ломает концепцию текстового документа. Пришли к той же проблеме, что кидалась в сторону JS.


    И со старыми косяками и «особенностями». Такое себе. Плюс новые фичи иногда добавляют так что лучше бы не добавляли.

    Тут хотя бы новые фичи добавляют именно для пробы и делают непосредственно частью платформы после тестов и применений в живую. Те же Observable убрали в пользу Proxy.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Вполне дается. Просто в отличии от кучи других языков приходится помнить про 100500 ограничений и всякого маразма который довольно сильно мешает жить.

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


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


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


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

    Я не против WebAssembly даже только за, НО и там найдётся свои недостатки уж поверьте.


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

  • Новая эра веб-разработки или «всё уже есть»
    0
    Мы бы банально не пытались лепить из документа приложение.

    Как это не пытались? А само существование флеша это разве не та самая попытка? Вы ведь всё-равно флеш встраиваете в HTML, так же как и JS.


    Да куда хуже чем сейчас то? Ну и под jvm внезапно есть не только компилятор java, а куча еще других языков в том числе и не статически типизированных. А это позволяет спокойно развивать и измерять язык. Что сейчас весьма сложно делать в js из-за как раз обратной совместимости.

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


    Под JVM есть язык для математиков Matlab, вот только он падает завидной частотой, ясно дело что это зависит от условий, однако другие почему-то в этих условиях и стеме же задачами (например Python) не падают.


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

  • Новая эра веб-разработки или «всё уже есть»
    0
    А что у меня там будет? Вот у меня сервер, для того чтобы браузер запустил оттуда какой-то код, я ему должен его как-то отдать. Если я отдам ему файл с js он его не будет исполнять.

    Так JS разве не код? любой другой набор данных не может быть этим кодом? Будет исполнять, если реализовать это в браузере. Вообще если реализовать спецификацию HTTP, а именно заголовки LINK, то вы можете просто отправить text/plain с заголовком LINK на скрипт или ещё лучше. Если браузера сам будет запускать этот код, например как Deno.


    Я это отлично знаю, а DOM туда пытаются запихнуть потому что внезапно стало надо рендерить html. Ой и вернулись к нему обратно.

    Если не было бы HTML, DOM бы всё-равно был, возможно слегка в ином виде, но был бы т.к. ой внезапно нам всё ещё нужно что-то рендерить иначе какой это браузер (обозреватель)?


    Приложение продолжает его эксплуатировать.

    По тому, что обратная совместимость.


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

    А я вижу обратную картину, ведь Веб это не одни лишь HTML да JS с CSS. Это в первую очередь Сеть обмена данными, привычный протокол в которой это HTTP, но есть и куча других.


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

    Ну началось, может проблема не в JS в вас? В том, что вы не работаете с ним в чистом виде и соответственно не разбираетесь в его природе/сущности и том как он работает?


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

  • Новая эра веб-разработки или «всё уже есть»
    0

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


    Если современный веб не устраивает (а ввиду обратной совместимости это врят ли изменится) рекомендую начать инициативу по созданию своего стека технологий/браузера. Вот там и посмотрим какая версия выживет в итоге.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Убило его больше не желание adobe открыть технологию.
    Не только, моральное устаревание реализации, а т.к. это не часть веба и тем более проприетарно не страшно было отказаться.

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

    Наличие флеша не избавило бы от html+js или любая другая пара технологий внутри флеша.


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

    А если не будет? А если тем более не JVM? И благо, что не JVM. Java знаете ли тоже не менее кривая и косая (подставьте на место Java любой ЯП).

  • Новая эра веб-разработки или «всё уже есть»
    0
    Который все равно будет html документом иначе браузер не запустит это все на исполнение и при этом создастся DOM.

    Не будет HTML кто вам такую чушь сказал вообще? То, что теги просто удобно для отладки и восприятия использовать не значит, что DOM внутри это тэги. DOM это дерево объектов/компонент такое же как и у нативных приложений. А вообще отправляю вас поизучать исходники браузеров хоть Chromium, хоть движок Servo.


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

    Node.JS пошел именно из исходников браузера, если точнее это V8 движок и отсутствие компонент отрисовки интерфейсов Layout, DOM, CSSOM, Parser и то туда думают впихнуть DOM обратно. Однако есть проекты по типу Electron, где эти компоненты вернули. Как я сказал убираем HTML Parser и получаете свою мечту.


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

    Это не проблема, а прогресс. HTML это не приложение если мы продолжаем речь о нём. Если уже о браузерах (А EMAIL/FTP клиенты по сути имеют ту же идею, что и Браузеры), то просто в них увидели потенциал именно платформы — распределённой платформы и всё.


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

    Веб такой популярный из-за обратной совместимости.


    Банальный биндинг полей требует кучи телодвижений прям в браузере.
    Построение интерфейса в нативном приложении такой же банальный биндинг параметров кучей телодвижений прям не отходя от кассы.
  • Новая эра веб-разработки или «всё уже есть»
    0

    Можете, убираем необходимость парсинга HTML. На уровне браузера можно просто получить заголовок LINK с сылкой на скрипт так же создать для него окружение с DOM и в этот DOM ничего не писать т.к. не парсим. В Node.JS нет отрисовки, но JS код работает. Оставляем от браузера только компоненты V8 VM, Layout, CSSOM, DOM и готово.


    Более того приложения на современных фреймворках продолжат работать ведь они работают не с HTML, а именно с DOM.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Нет там никакого 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

  • Новая эра веб-разработки или «всё уже есть»
    0
    В том то и дело что не играет. В вебе ближайший аналог того как это работает в андроиде и других ОС это canvas.

    Нет, по секрету скажу, что даже HTML отрисовывается в Canvas уровня приложения это то же view, что и при использовании XML и другого механизма OM (дерева объектов), к которому вам не дают доступ, как в случае веба через DevTools и в представлении HTML, чтобы вам как человеку было проще ориентироваться в этом графе.


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

    Можете, но делаете это вы на аналогичном *OM API, я так же могу не прописывая HTML собрать такое же представление используя только DOM API и выше я привёл примеры и даже с XML и просто текстом.

  • Новая эра веб-разработки или «всё уже есть»
    0

    DOM работает без HTML, откуда вы взяли, что он без него не работает. При загрузке страницы HTML используется браузером только на начальном этапе, чтобы перевести структуру HTML в дерево виртуальных объектов (DOM). А дальше уже работа именно с виртуальным деревом, а не файлом/текстом как таковым. То, что вы можете в DevTools посмотреть это дерево в HTML представлении и выгрузить его так не означает, что внутри это работа с текстом.


    Я могу создать документ используя DOM API и собрать там произвольное дерево.


    const doc = document.implementation.createDocument ('http://www.w3.org/1999/xhtml', 'html', null)
    const body = doc.createElement('body')
    const headline = doc.createElement('h1')
    
    doc.documentElement.append(body)
    body.append(headline)
    headline.innerText = 'Hello world!'
    
    doc.documentElement.outerHTML
    // <html xmlns="http://www.w3.org/1999/xhtml"><body><h1>Hello world!</h1></body></html>

    И это без HTML только DOM API.


    Или вот использую DOM API для построения XML дерева.


    const doc = document.implementation.createDocument(null, "books")
    const book = doc.createElement('book')
    doc.documentElement.append(book)
    book.setAttribute('id', '1234567890')
    book.innerText = 'Book name'
    
    doc.documentElement.outerHTML
    // <books><book id="1234567890"/></books>

    Или вот дерево из строк:


    const doc = document.createDocumentFragment()
    doc.append('Hello ', 'world ', 'dear ', 'friend!')
    
    doc.textContent
    // Hello world dear friend!

    Это к тому, что DOM это именно представление в виде дерева объектов. И такие же аналоги деревьев объектов используются и в нативных приложениях.

  • Новая эра веб-разработки или «всё уже есть»
    0
    Не меняем. Это свойство объявленного компонента. И в 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 это по сути именно приближение к нативным приложениям, вьюхи и клиентская логика которых лежит именно у клиента, а не где-то на сервере.


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

  • Новая эра веб-разработки или «всё уже есть»
    0

    Ну и ещё вкину связывая и с предыдущими вашими комментариями. Когда вы делаете интерфейс приложения без xml вы используете какие-то API для построения интерфейса, а эти API есть аналог DOM в вебе.

  • Новая эра веб-разработки или «всё уже есть»
    0

    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.

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

  • Новая эра веб-разработки или «всё уже есть»
    0
    Простите, что?
    Как структурированные данные вообще в принципе могут быть документом?

    Ок, ок если будем придираться, то и 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 именно о типе документа.

  • Новая эра веб-разработки или «всё уже есть»
    0

    Ну как не меняете, а как же смена экрана (одной xml на другую) иначе интерфейс был бы статическим и причина не в отзывчивости. Вы всё-равно вызываете какой-то метод на Java/Kotlin/C#/C++, чтобы поставить другую xml на вьюхе. Опять таки всё абсолютно так же.


    По поводу поисковых роботов, как бы уже всё-равно они умеют в JS и т.д. с хитростями, но всё же. Например, текущий GoogleBot работает на базе Headless Google Chrome 80 и начиная с прошлого месяца он EverGreen т.е. обновляется синхронно с бразуером. У Яндекса так же +-.


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


    А причина переноса всего фронтенда (клиент и сервер) на JS в желании оптимизировать разработку, ведь это удобно, когда один и тот же код работает как на клиенте, так и на сервере. И к этой оптимизации уже с 2015 года некоторые пришли.

  • Новая эра веб-разработки или «всё уже есть»
    0

    Вообще вся эта ветка комментариев это просто "Раньше было лучше" и "В наше время" и применить это можно к чему угодно, хоть к появлению языка Swift или Kotlin. Но время идёт, меняются реалии, цели, задачи.

  • Новая эра веб-разработки или «всё уже есть»
    +1

    Ещё раз такая же ситуация.


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

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


    Но если у меня html+js то отключение js приводит к показу печальной таблички ой у вас отключен js.

    Это зависит от того как вы реализуете свой сайт HTML+JS, если используете прогрессивные методы, то в случае отключения JS просто откатитесь до HTML-only, который как вы чуть раньше указали будет работать без всякого JS. А вот если вы делаете SPA со 100% отрисовкой на клиенте, то да будете показывать табличку.


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


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

    Отлично, в браузере можно успешно работать без html, используя только DOM API, собственно оставив только JS кусок кода из моего примера и работая через DOM API я получу тот же результат, что и используя декларацию в HTML посредством <template>.


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


    Как бы вам не кажется весьма странным тащить в html документ линковку и компиляцию?

    Никто их именно в HTML не тащит это строго рамки JS и весь код на JS.


    Xml в приложения пошел для упрощения описания интерфейса. Идеи Delphi живут и здравствуют.

    В случае html мы имеем другой путь. Был html который использовался для документов. Потом туда добавили js и это стало путем когда свернули не туда. По этому сейчас и имеем костыль на костыле

    Был Delphi, потом в него добавили XML для документов. Ситуация абсолютно зеркальная. А как же привычные форматы документов, презентаций, таблиц, которые к слову тоже архивы, тоже с xml и тоже в которые добавили макросы (язык программирования).


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


    Веб (та часть про http/html/js/css) просто поменял вектор, раньше был только про документы, потом про документы с условно макросами (JS), а сейчас в платформу, вот только эта платформа обратно совместима с предыдущими векторами развития. И использование ряда технологий веба не по первоначальному назначению именно связано с обратной совместимостью, естественно можно разработать что-то с нуля и выкинуть старое (то, что близко, но было переосмысленно), но мы тогда потеряем простые документы.


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


    Вообщем веб только на пути к правильной платформе та же инициатива по Web Components / Custom Elements существует и реализуется с 2016 года, но уже 5 раз переделывалась и ещё на стадии 30-40%. Были и импорты отдельных html именно как шаблоны, в результате deprecated, сейчас они вновь возраждаются, но уже не в качестве <link rel="import">, а HTML/CSS модулей в JS. import template from './contact-item.html'


    И к слову webpack это просто сборщик, условно компилятор только для веба.

  • Новая эра веб-разработки или «всё уже есть»
    +1

    С HTML ситуация абсолютно такая же, поверьте. И ваш пример с отключением JS применим и к нативным приложениям с Java/Kotlin/C#/C++, вот только в них опции отключения этих языков не предоставлено как в браузере. По поводу линковки в нативные компоненты в вебе есть такая штука как Custom Elements, работающая именно так же. Ведь эта самая линковка ничто иное как описание, что этот класс реализует этот шаблон не более. И опять таки убрав реализацию шаблона в xml кодом на Java/Kotlin/C#/C++ интерфейс нативного приложения просто перестанет работать.


    Пример Custom Elements в HTML / JS:


    <custom-checkbox></custom-checkbox>

    class CustomCheckbox extends HTMLElement {
        #isChecked = false
    
        get checked() {
            return this.#isChecked
        }
    
        constructor() {
            super()
            this.addEventListener('click', this.onClick.bind(this))
            this.updateRendering()
        }
    
        onClick () {
            this.#isChecked = !this.#isChecked
            this.updateRendering()
        }
    
        updateRendering() {
            this.innerText = this.#isChecked? 'X' : 'O'
        }
    }
    
    customElements.define('custom-checkbox', CustomCheckbox)

    Для декларации содержимого элемента по примеру с декларацией в xml создан тег <template>.


    <template id="contact-item">
        <li class="contact-item">
            <img class="contact-item__picture" alt="Contact Picture">
            <span class="contact-item__name"></span>
        </li>
    </template>
  • Новая эра веб-разработки или «всё уже есть»
    0

    Проблема надумана, xml тоже документ. Но мы пытаемся сделать из него приложение при помощи Java/Kotlin/C#/C++ на платформах Windows и Android. И почему-то это не идёт в разрез концепции, а в случае пары HTML / JS идёт. По моему суждения подобные вашему странны, ведь нативные приложения строятся так же.