Telegram объявил конкурс для JavaScript-разработчиков с призовым фондом от $200 тысяч Статьи редакции
Участники должны написать упрощённую версию веб-приложения.
Telegram запустил конкурс для разработчиков, пишущих на JavaScript. Он пройдёт в три этапа с 3 по 17 ноября.
Задача конкурса — разработать упрощённую веб-версию Telegram без использования сторонних UI-фреймворков. Готовое веб-приложение должно состоять из интерфейса авторизации и регистрации, а также позволять просматривать список чатов и сообщения.
Архив с макетами доступен в официальном канале, через который Telegram объявляет конкурсы. Документация по API и исходный код существующих клиентов Telegram опубликованы на сайте мессенджера.
Основными критериями при выборе победителей будут размер веб-приложения, скорость его работы и внимание разработчиков к деталям. Компания учтёт, если сервис получит дополнительные функции, такие как отправка сообщений, просмотр медиавложений, настройки и так далее.
Использовать UI-фреймворков вроде React и Angular нельзя. Использование библиотеки данных TDLib теоретически возможно, но, скорее всего, может привести к увеличению времени загрузки по сравнению с простыми JavaScript-решениями.
Призовой фонд первого этапа составит $80 тысяч. В описании не написано, сколько победителей Telegram планирует отобрать. Призовой бюджет для всех трёх этапов составит от $200 тысяч.
А ВК объявляет конкурсы по 100 000 руб.
Бедняга :( Именно это тебя останавливает в них участвовать?
Я не специалист, но у меня вопрос. А что так сложно написать приложение на javeS
Сложно.
1 - Сейчас 80%+ JavaScript разрабов это исключительно ребята, научившиеся пользоваться фреймворком А, B, C.
2 - Если делаешь продукт на фреймворках, то это жутко не эффективное рассходование средств фирмы и переписывание продукта раз в 5 лет, но так делают все. Плюс весит все это много. Работает по факту медленно, чтобы Вам там не говорили.
3 - Приложение без фреймворков может написать от силы 1-3% JS разрабов. Реально написать, а не сказать что смогут.
Без фреймворков все работает мега быстро, но сделать не гавнокод на выброс, а продукт
нереально сложно. Уровень таких спецов, это не Senior разрабы, а архитекторы.
P.S.:
Не скромно скажу, что я бы смог такое сделать. 12.5 лет с JavaScript. Кучу Enterprise софта написал без фреймворков.
Но
1 - За чем мне это надо.
2 - Хорошие продукты делаются либо быстро, либо хорошо.
"с 3 по 17 ноября." - гавнокодинг на скорость с 14-18 часовым рабочим днем в лучших традициях экстремального программирования.
3 - Все эти конкурсы, это чисто наша тема. Не уважения к труду людей.
Обычно такую хуйню несут люди которым выгодно пропихивать свое костыльное решение. Потому что их хуй выгнать или заменить ибо поддерживать и разбираться в этом говне нереально.
О разработке js софта без фреймворков от моего конкурента.
https://realtalkjavascript.simplecast.fm/99e4af34
Не очень понимаю как подход к разработке библиотек относится к подходу разработки конечных продуктов.
Абсолютно разные цели и средства.
Даже не знаю с чего Вам начать это все обьяснять. Эта тема для очень большого спора, ругани, обсуждений, примеров и доказательств.
Если поверить на слово не можете, то считайте что правы.
Ну давайте не будем скатываться до "ой все"
Еще в бородатом 2008 писал энтерпрайз без фреймворков и без jQuery на 40-50 экранов с XML на бекенде.
Потом дорабатывал англичанам их внутреннее решение, тоже без фреймворков.
И за время карьеры писал на Ext.js Backbone, Knockout, Amber, Angular, React, Vue, сейчас ковыряю Svelte и смотрю в сторону Kotlin
Так что имею представление о чем говорю.
Есть куча критериев по которым нужно сравнивать любое решение в разработке. И сорян, но "продукт на фреймворках, то это жутко не эффективное рассходование средств фирмы и переписывание продукта раз в 5 лет" это аналитика уровня /b/
Мне не хочется ругаться с Вами на 100 комментов.
Считайте что Вы правы.
Бред. Кастомизированное решение под задачу всегда лучше универсального, а то, что единого универсального на все случаи жизни и времена фреймворка так и не создано - только подтверждают этот тезис.
"всегда лучше" - популизм
По каким критериям?
По любым, кроме стоимости разработки и стоимости сопровождения другой командой. Да, кастомная разработка стоит дорого, но если деньги есть, то универсальные решения ей сольют.
"По-любым" это только "по скорости работы" и то сильно зависит от разработчиков.
Итого из
- стоимости разработки /скорости разработки
- стоимости поддержки и сопровождения
- скорости работы
Имеем только последний пункт и то не на 100%
"всегда лучше" ага :)
Конечно зависит от разработчиков, иначе из-за чего бы была большая стоимость разработки. Это даже не обсуждается, но я исхожу из потребности. Если деньги на проект есть, то найти качественных разработчиков, которые смогут реализовать все преимущества кастомного решения, не проблема. Собственно, те же самые JS фреймворки когда-то и были внутрифирменной, кастомной разработкой.
Комментарий недоступен
Комментарий недоступен
100 килобайт кода - это не 100 килобайт текста. Это все
- парсится
- раскладывается на AST
- пытается оптимизироваться
- переводится в байткод/подстраивается под конкретный машинный процессор
посмотрите, кажется, на Хабре были об этом статьи. Для десктопа это особой роли не играет, но вот для телефонов - играет. У мобилок пауза ожидания, пока все скрипты переварятся, может до 10 секунд и больше составлять.
PS: вот
https://habr.com/ru/company/mailru/blog/321748/
100кб кода роли не играет? Хорошо, да. Только потом не удивляйтесь, что это «роли не играет» отжирает всю вашу оперативку, забивает проц и вообще загружается через раз
Дада, жутко не эффективно:) А переписывать спагетти говнокод за очередным мамкиныным архитектором это выгодно и эффективно? Фреймворки стандартизировали написание фронта и принесли порядок в хаос фронтенд разработки, когда как раньше любая макака писала отсебятину:)
А фреймворки с неба упали что ли? Их кто-то написал. И написал для определённых применений, приняв определённые архитектурные решения и компромиссы. Следовательно, разработчик, сумевший разработать фреймворк, сможет сделать и кастомное решение.
С фреймворком напортачить спагетти код тоже запросто можно, особенно в тех случаях, которые выходят за рамки его применения, заложенными в его архитектуре. Окостыливания того же Реакта или Ангуляра немало.
Тредик дичи. любой фреймворк, в более менее крупном проекте, обрастет "кастомным кодом". Ибо не всемогущ. А в небольшом проекте фреймворк тем более нафиг не нужен. В итоге итог.
Написать полное дерьмо - не составляет труда. Можно пойти простым способом и взять уже половину готовых библиотек. Размер приложения будет не оправданно больше. Поддерживать такое и развивать- будет болью для нового разработчика.
Написать без готовых решений так, чтобы это весило мало, работало ок и потом это можно было развивать и добавлять новый функционал - нужно пораскинуть мозгами.
Я думаю, что так в любом деле. Всё зависит от того, как заморочиться и сделал максимально качественно.
Как будто фреймворки это что-то плохое, в эпоху, когда 5g на пороге, вы волнуетесь о нескольких лишних мегабайт?
https://habr.com/ru/company/ruvds/blog/468407/
Отправка сообщений для мессенджера это дополнительная функция?
Цель — лёгкий и быстрый интерфейс в первую очередь без фреймворков. Отправка сообщений в твоём проекте это уже опционально и будет типо бонусом/плюсом в принятии решения проверяющими.
Это конкурс и скорее всего то, что ты сделаешь не пойдет на продакшн. Ну или с сильными изменениями.
Запилите уже преобразовывание ссылок на телегу на открытие телеги, лень впн подрубать каждый раз
Комментарий недоступен
Тот случай, когда заработать 80 тысяч проще, чем выиграть.
Нужно понимать, что эти деньги просто раскидают на всех призёров. В прошлом конкурсе их было овердохера. Но свои 1-2к долларов, может и получишь, если повезет.
Тем более
А никого не смущает, что дизайны в виде JPG файлов приложены? Линейкой отступы замерять и пипеткой цвет определять не удобно.
Приложены пнгхи (херовый аргумент, это я просто доебался).
Там есть стайлгайд в файлах (файлик приложил).
Остальное посмотрел и не нашёл стайлгайдов по отступам и цветам. Но в самом соревновании написано: "Почитайте исходный код текущего приложения, окда?", что можно читать как "Ну нам ващет нужны разработчики, которые и без стайлгайда сделать могут что-нибудь. Вот вам код, читайте".
Подход, как минимум, дискуссионный.
Комментарий недоступен
Телеграм постоянно какие-то конкурсы пилит. Жаль что я не разработчик. Думаю очень интересно создать что-то упрощенное так еще и получить кучу денег за это...
У них и для дизайнеров конкурсы есть
TS можно?
Тоже интересно можно ли использовать typescript.
У них говянное жюри, потому пошли они в жопу со своим конкурсом, ахахаха 🖕
Комментарий удален модератором