JQuery это какой-то ад. Я очень рад тому что в свое время не стал тратить время на его изучение.

У тебя на веб вообще несварение

На питон тоже

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

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

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

Ну частично да, зато неадекватное количество модулей на все случаи жизни

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

Кривые технологии? Где в jQuery кривые технологии?

Да как по мне он крив на 100% там какие-то элеентарные вещи делаются через зад и тонной кода

Ну частично да, зато неадекватное количество модулей на все случаи жизни

понятное дело, плагины-хуягины, но «изучать-то» там по большому счету нечего)

Да как по мне он крив на 100% там какие-то элеентарные вещи делаются через зад и тонной кода

Какие элементарные вещи? + ты точно писал на ванильном JS?

Ну и да, реактивность это действительно круто

вот всякие vue, react, angular, да, там своя философия, архитектура и подходы)

Да как по мне он крив на 100% там какие-то элеентарные вещи делаются через зад и тонной кода

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

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

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

Поддержка IE6 и компании

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

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

На практике на ваниле кода раза в 2 больше

Я не вижу смысла писать на ванильном JS

а чего бы не писать на ванильном js?)

Я не вижу смысла писать на ванильном JS

А я не вижу смысла объедаться сахаром и орать, что менее сахарное - говно

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

А я не вижу смысла объедаться сахаром и орать, что менее сахарное - говно

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

будет нужен TS?)

TS это CoffyScript 2.0 с той же судьбой

ну не сказал бы

вот, кстати, по поводу мультиязычности меня пугает другая тенденция: программисты, активно использующие JS, пытаются переписать всё на JS)

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

Так дело не в том, что решает твои задачи. Дело в том, что ты орешь что-то про неправильные технологии. Хотя в jQuery нет никаких новых от ванильных технологий, это просто обертка. Даже подход практически идентичен ванилю. // Vanilla ES6 Array.from(document.querySelectorAll('.class')).forEach(e => e.addEventListener('click', () => alert('hello'))); // jQuery $('.class').on('click', () => alert('hello'));

вот, кстати, по поводу мультиязычности меня пугает другая тенденция: программисты, активно использующие JS, пытаются переписать всё на JS)

Это да. Меня от тормозов получившихся решений просто передергивает.

Это да. Меня от тормозов получившихся решений просто передергивает.

Тормоза от DOM'а, V8 делает JS одним из самых быстрых скриптовых ЯПов

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

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

Это не проблема jQuery

Тормоза от DOM'а, V8 делает JS одним из самых быстрых скриптовых ЯПов

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

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

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

Давай еще раз уточним: проекты с гуем или консольные проекты?

это не реактивный фреймворк, не MVC и не вот это вот всё

Давай еще раз уточним: проекты с гуем или консольные проекты?

И те и другие.

И те и другие.

Первые тормозят, как я уже сказал, из-за DOM'а

В принципе у них скорость как у нормального браузера

Как минимум vue появился лет на 10 позже jquery так что неудивительно что он более логичный

С тормозами правильно спроектированных вторых, я никогда не сталкивался

За 10 жс пережил огромную эвореволюцию

Как минимум vue появился лет на 10 позже jquery так что неудивительно что он более логичный

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

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

И нормальную поддержку ассинхронности и многопоточности

В современных альтернативах JS этих киллерфич нет

Так в go есть

Так в go есть

Так я про фронтенд

В бэкенде нода точно не выиграет

Разве что как сборщик

Васм должен уже дать возможность на чем угодно писать фронтенд

Это востребованно

Васм должен уже дать возможность на чем угодно писать фронтенд

WASM не поддерживает многопоточность и работу с DOM

Это пока

Он же еще допиливается

Пока то, пока се

у меня есть стойкое ощущение, что в этом плане веб свернул куда-то не туда)

у меня есть стойкое ощущение, что в этом плане веб свернул куда-то не туда)

Точнее, он не может куда то свернуть из-за обратной совместимости :)

Скидываться на фичи могли бы не отдельные кодеры, а фирмы

у которых есть расчёты человеко-дней

у меня есть стойкое ощущение, что в этом плане веб свернул куда-то не туда)

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

Вот-вот. Все сильный ИИ уже к 2025 году обещают.

Вот-вот. Все сильный ИИ уже к 2025 году обещают.

Кто обещает?))

Ну я кучу прогнозов читал. Все говорят что не позднее 2025 года будет.

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

ну так чисто теоретически

Ну чисто теоретически dmd так может

Ну я кучу прогнозов читал. Все говорят что не позднее 2025 года будет.

Это прогнозы из разряда вдвое увеличить ввп за следующие два года)

ERROR: S client not available

Тоесть ты думаешь сильный ИИ в ближайние 7 лет не сделают?

Ну, как тебе сказать, сильный ии — это концепция из области философии сознания)

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

Сильный ии зайдет в телеграм и всех затроллит

Очень сильно

Ну чисто теоретически dmd так может

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

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

Э...

Тебе только аллокации или их высвобождение тоже надо?

Ну хотелось бы вообще в динамике видеть что в приложении происходит. Я пока просто чисто теоретически спрашиваю. Реального кейса нет

Ну хотелось бы вообще в динамике видеть что в приложении происходит. Я пока просто чисто теоретически спрашиваю. Реального кейса нет

Чисто теоретически - патчить GC и аллокации. Я так понимаю, не святым духом аллоцирует и высвобождает

Чтобы там каждый раз эти метрики через какой-то интерфейс выдавались?

Чтобы там каждый раз эти метрики через какой-то интерфейс выдавались?

Ага

Кстати, а если в Ди засунут async/await то не получится ли что язык просто еще сложнее станет? Типа фишек все больше, а целостности нет

Кстати, а если в Ди засунут async/await то не получится ли что язык просто еще сложнее станет? Типа фишек все больше, а целостности нет

А зачем в D async-await?

Вот тут про них спрашивают https://forum.dlang.org/post/tpgwfedrlnvnmgvljuyp@forum.dlang.org

Коммент Ольшанского по делу: "God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes."

В плюсах что-то неприятное мутят с асинками :-( В Go сильно проще и удобней.

Мля я даже представить не могу что такое должно быть в голове у людей чтобы вместо прекрасных файберов предлагать какие-то костыли async/await

Ссылаясь на то что в каких-то там языках это есть

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

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

Будут затухать. Просто будут новые языки.

Ссылаясь на то что в каких-то там языках это есть

Особенно ссылаясь на шарп и жабашкрипт.

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

Архитектуры железа сильно меняются. Так что..

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

Олег, ты кажется сокетами занимался. Вот может пригодится https://martinnowak.github.io/io/std/io/net/socket.html

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

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

это как так?)

Да это понятно. Только реальная жизнь часто требует компромиссов. Я уверен если бы в std была крутая либа для GUI все бы только радовались этому и это была бы кил-фича

не в std, а официальное GUI отдельной либкой

либо чтоб сказали, "вот dlangui официальное гуи, все пилим его"

https://wiki.dlang.org/GUI_Libraries вот хер пойми что вьібрать + по всем хєровая документация

для новичков не ок