Stack Overflow опубликовал рейтинг любимых у разработчиков языков программирования за 2023 год — на первом месте Rust Статьи редакции
А также опросил программистов по поводу любимых ИИ-инструментов: ими оказались ChatGPT и GitHub Copilot.
- Один из крупнейших форумов для разработчиков Stack Overflow опубликовал ежегодное исследования рынка ИТ. В нём участвовали 90 тысяч программистов.
- В рейтинге самых часто используемых языков первое место занимает JavaScript — он возглавляет список уже 11 лет. На втором — HTML/CSS, на третьем — Python.
- Stack Overflow переработал рейтинг языков программирования, с которыми разработчикам нравится работать больше всего. Теперь он показывает соотношение программистов, которые хотят использовать язык, и тех, кто уже его использовал и планирует делать это и в будущем.
- Например, несмотря на популярность JavaScript, только около 40% программистов хотят его использовать, 57,83% — уже попробовали и хотят пользоваться им дальше. Самый популярный — Rust (соотношение 30,56% и 84,66%). Он возглавлял список любимых языков программирования в 2020-м, 2021-м, 2022-м.
- Также среди любимых Elixir, Clojure, Zig и Raku. Самые непопулярные — Matlab и Cobol. Попробовали и хотят использовать их в будущем 18,31% и 20,33% опрошенных разработчиков.
- Среди облачных платформ на первом месте — Amazon Web Services, на втором — Microsoft Azure, на третьем — Google Cloud.
- В исследование добавили новый раздел — про ИИ-инструменты. Около 70% опрошенных уже их используют или планируют в будущем. Чаще всего к ним прибегают начинающие разработчики. Также большинство (77%) одобряет использование ИИ для программирования.
- Среди плюсов они называют повышение производительности и ускорение обучения. При этом доверяют точности результатов ИИ только 42%. Используют ИИ-инструменты в основном для написания и отладки кода.
- В рейтинге инструментов для поиска самые любимые — ChatGPT, Phind и Wolfram Alpha. Также разработчики хотели бы в будущем и дальше использовать Bard и Bing.
- Среди инструментов разработки первое место у GitHub Copilot. На втором и третьем — Codeium и Whispr AI.
42K
показов
18K
открытий
7
репостов
Только этот JavaScript в основном фреймворки на нём, а не сам JavaScript
Если уж фреймворки, то тогда и js нет, только ts.
ts даже не 10-ке 🤷♂️
Или думаешь алгоритмы StackOverflow, ts считают за js? Это вряд ли. А вот всякие jQuery и Vue они считают за js.
Ок, не заметил) Наверно, потому что, я далек от TypeScript. JavaScript просто нативный для браузеров, его должны знать все, даже не программисты, например, чтобы быстро исправить код на странице или написать правило для Node.js Lambda функции, а вот TypeScript уже более узкоспециализирован.
Вопросы по JS в основном - это базовые вопросы от новичков, там огромное количество, плюс как работать с DOM. Вполне вероятно, что и jquery обсуждают (кстати, есть современная версия cash). Но не думаю, что львиная доля вопросов это обсуждение фреймворков на JS.
А вот что касается фреймворков, то можно заметить, что весь мейнстрим уже на TS. Да, и тот же Vue.
Если сейчас может кто-то еще и работает с тем же Vue 2 на JS, то таких скоро будет мало.
У JS есть одно безусловное преимущество перед TS - он работает в браузере. Казалось бы - какая проблема добавить новый язык в браузер? Тот же dart, например? Или Wasm? А вот не прорастает почему-то. Вот и транспилят код TS-разрабы, придумывая всякие ухищрения, чтобы делать это побыстрее. А потом при отладке на live тупо смотрят в DevTools - а где мой код? Где-где... в IDE остался!! :D
да, проблема.. ну даже если тс не добавляют в браузер - вот бы придумали такую штуку, чтобы можно было смотреть какой кусок исполняемого кода соответствует какому куску исходника.. ну что-то типа карты. надо будет придумать и запатентовать
Вы идёте правильным путём, товарищ. Это называется map-файлы и они обычно выкидываются в live-сборках для уменьшения веса.
https://stackoverflow.com/questions/17493738/what-is-a-typescript-map-file
Тока хотел сказать про них. Помню когда начинал тока в 15-16 годах, не понимал зачем нужны эти «лишние» файлы 😂
ну вообще да.. сейчас фронтенд настолько жирный стал, что хотелось бы его уменьшить хоть немного... тем более, что могут быть проблемы с сетевым оборудованием у провайдеров, надо оптимизировать код!
а что если придумать такую софтину, которая будет человекочитаемые названия в коде уменьшать до 1-2 букв, убирать лишние пробелы и т.д. .. я бы назвал её минификатором кода. надо допридумать и запатентовать, если её еще не придумали.. не придумали ведь?
И вы опять идёте правильным путём! (y) Даже название удачное подобрали :) Жаль только, что всё это уже придумано до вас :( Вам надо чуть глубже вглядываться в будущее. С такими способностями вы точно когда-нибудь что-нибудь изобретёте первым. Только не останавливайтесь!
Да в жопу этот фронт, пойду на бэке что-нибудь придумаю..
А у меня вопрос возник - вот если в продакшоне у нас нет map файлов и код мы минифицируем, то в чем преимущество js перед ts?
Я вот свой код не минифицирую, у меня и преимущества есть:
ну так включите в сборщике sourcemap и вперед в мир ts (хотя там уже сахара не осталось, только типы, но все равно)
А зачем? Тратить время на транспиляцию? На каждом чихе? Мне JSDoc'ов хватает, чтобы в коде не потерятся. Пусть транспиляют те, кто не умеет в JSDoc'и ;)
А на объёмы результирующего кода мне глубоко фиолетово. Я для мобильных приложения делаю, а там с устройствами меньше 256 гигов постоянной и 4 гигов оперативной в обществе неприлично показываться.
"TS не нужен, родной!" ;)
Ну, кстати, интересная позиция. И довольно непопулярная. У вас есть опыт работы с TS? Интересуюсь, потому что хочу понять когда jsdoc не хватит для прода.
Если не ошибаюсь, что на jsdoc можно и интерфейсы писать, кастомные типы, структуры объектов. Какие-то есть неудобства?
Я начал серьёзно писать на JS года 4 назад. К тому времени уже 4 года как был ES6. У меня есть опыт работы с GWT (java-to-JS) и очень отрицательное отношение к транспиляторам именно из-за сложностей отладки в проде. Поэтому я изначально не рассматривал TS как вариант.
Ирония в том, что JSDoc для прода практически не нужен. Он нужен только на моменте разработки - чтобы выстроить в голове схему работы программы. А на проде более полезен отладчик. Вот только когда код прода значительно отличается от кода в IDE, разбираться значительно сложнее. Поэтому, согласно "принципу наименьшего удивления", я стремлюсь к тому, чтобы код в IDE и в браузере был максимально идентичен. Мне не понравилось то чувство бессилия, которое я испытал, впервые увидев транспилированный Java-код в браузере.
Да, в JSDoc можно и в интерфейсы :) Для ванильного JS штука бесполезная, но если применять Dependency Injection, то очень помогает в документировании. В общем-то, получается что ты пишешь JS-код для процессора, а сверху накладываешь JSDoc'и для IDE, которая помогает тебе ориентироваться в твоём же коде. У меня IDEA и я вырабатывал свой стиль документирования под неё. Я не знаю, смог бы я писать свой код в VSCode или в Eclipse.
https://habr.com/ru/articles/569384/
Спасибо за крайне содержательный комментарий. Во многом солидарен. Мы сейчас пишем только в VSCode. Там проблем нет с подсказками. И, кстати, тоже преимущественно на JS (JSDoc используем избирательно). Все присматриваемся к TS, но его пока не берем, потому что любим экспериментировать и используем свои самописные сборщики. Сейчас на крайнем проекте перешли на ES6-модули просто чтобы идти в ногу со временем. Другой причины нет. Используем Rollup для сборки кода. Минификацию также используем, но при этом идентификаторы не переименовываем для удобства отладки. JSDoc нравится тем, что еще документацию может сгенерировать. В принципе им довольны.
Теперь о вашей публикации на Хабре. Что касается импортов, то в VSCode есть автоматическая простановка. Начали что-то писать, используем какой-то класс или функцию, если VSCode видит, что они определены в одном из модулей, то вставит строчку кода с импортом в начало редактируемого модуля. Раздувать дискуссию я не буду. При наличии вопросов можно и в личку.
Ну вот, и у вас есть положительный опыт использования JS + JSDoc! (y) Не уверен, что вам понравится TS в таком случае. Как написал чуть выше Иван Иванов - "там уже сахара не осталось, только типы". А референсы по типам вам и JSDoc сделает. TS был хорош до появления ES6, IMHO.
Когда я начал плотно писать на JS у меня была цель писать на одном языке (JS) всё веб-приложение - и фронт, и бэк (nodejs). Оказалось, что межпакетный (npm) import не работает одинаково для фронта и бэка. Внутри пакета можно использовать относительную адресацию (import from '../../../path/to/es6.js), а импорт модуля из другого пакета выполняется для nodejs по-одному (from '@vendor/package/es6.js), а для браузера - по-другому. (Relative references must start with either "/", "./", or "../") Поэтому, чтобы можно было создавать shared-код, который из npm-пакета будет работать и на фронте, и на бэке, пришлось делать собственный autoloader и выдумывать всякое. Но разрабы не очень-то и ценять возможность писать на одном языке и фронт, и бэк :)
https://www.reddit.com/r/learnjavascript/comments/13qykae/what_prevents_javascript_from_being_the_sole/
Понял. Соглашусь. Для изоморфного приложения одного лишь изоморфного синтаксиса модулей не хватает. Потому что в принципе "пакеты" в браузере не используются. Поэтому да, приходится создавать di-решение, некий автолоадер таких пакетов. Как правило, это глобальный объект, который повторяет описание packages.json для работы с папкой node_modules.
Хорошая мысль.
Что касается того, что ценят разрабы, то это вообще отдельная, причем философская тема. У меня такое ощущение, что сейчас очень многие зомбированы мейнстримом. Поэтому маленькая вероятность, что кто-то будет с интересом читать об очередном велосипеде в мире веб-разработки.
Вот пример ванильного JS, который использует интерфейс (`@implements`)
https://github.com/flancer32/teq-ant-log-server/blob/main/src/Back/Web/Handler/Beacon.mjs#L16
и вот как он выглядит в IDE (можно переходить по Ctrl+click на описание интерфейса):
Вот работающая демка с WebAuthn, посмотрите вкладку Sources в DevTools - https://pk.auth.demo.teqfw.com/#/
Ну, сразу видно, что вы пришли из бекенда. Нестандартный подход. Надо время, чтобы вникнуть и понять идею почему именно так. Обсуждать технические детали на публику, я думаю не буду. В любом случае, благодарю.
Ни в чем. Вы ж его минифицировали :)
Типы данных добавят в нативный js, инфа сотка. Сейчас уже громче говорят о том, что jit-компиляторы в браузерных движках не любят полиморфизм в аргументах функций. То есть если в аргументе функции всегда примитив одного и того же типа или же структура данных не меняется, то оптимизация сработает. То есть на "системном" уровне уже подбираются к внедрению типизации. Если не изменяет память, то через asm.js хотели внедрить типизацию.
Искусственность TS - это одна из проблем в большом скопе. Например, сейчас кроме конвертации TS в JS есть еще компиляция (сборки) файлов компонентов в JS ))
Проблема в том, что вообще средства разработки ускакали от нативных решений довольно далеко. Поэтому неудивительно, что в рантайме мы можем получить не совсем то, что видим в IDE.
Код транспилят сейчас все кто не на жквери пишут.
А потом при отладке на live тупо смотрят в DevTools - а где мой код?https://developer.chrome.com/blog/sourcemaps/
Кто это вам сказал? Тот же Vue 3 позволяет писать фронт-код без транспиляции. Это у вас просто картина мира профдеформирована.
На live обычно map'ы не выкладывают. Кому они нужны после build'а? Вот в этом-то и основная жопа.
"позволяет писать" != "используют повсеместно"
Тот же jsx тоже можно без транспайлера юзать
На live обычно map'ы не выкладывают. Кому они нужны после build'а? Вот в этом-то и основная жопа.Мы сорсмапы заливаем в сентри чтобы получить нормальный трейс.
И плюс есть QA у которых есть задача сделать минимальный STR.
Если уж падать в логику, то "используют повсеместно" === "используют повсеместно" и ничему более. Так же, как и "позволяет писать" === "позволяет писать".
А "Код транспилят сейчас все кто не на жквери пишут" === false.
Мы сорсмапы заливаем в сентри чтобы получить нормальный трейс.Это здорово, но это не меняет того факта, что в DevTools браузера вы видите не то, что в IDE. Т.е., без Sentry вам клиента отдебажить будет проблемно. Да и с Sentry тоже. Логи проанализировать постфактум - то да.
Про QA с минимальным STR, к сожалению, беседу поддержать не смогу - это что-то на enterprise'овском. Непонятное.