Telegram объявил конкурс для JavaScript-разработчиков с призовым фондом от $200 тысяч Статьи редакции

Участники должны написать упрощённую версию веб-приложения.

Telegram запустил конкурс для разработчиков, пишущих на JavaScript. Он пройдёт в три этапа с 3 по 17 ноября.

Задача конкурса — разработать упрощённую веб-версию Telegram без использования сторонних UI-фреймворков. Готовое веб-приложение должно состоять из интерфейса авторизации и регистрации, а также позволять просматривать список чатов и сообщения.

Архив с макетами доступен в официальном канале, через который Telegram объявляет конкурсы. Документация по API и исходный код существующих клиентов Telegram опубликованы на сайте мессенджера.

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

Использовать UI-фреймворков вроде React и Angular нельзя. Использование библиотеки данных TDLib теоретически возможно, но, скорее всего, может привести к увеличению времени загрузки по сравнению с простыми JavaScript-решениями.

из описания конкурса

Призовой фонд первого этапа составит $80 тысяч. В описании не написано, сколько победителей Telegram планирует отобрать. Призовой бюджет для всех трёх этапов составит от $200 тысяч.

0
41 комментарий
Написать комментарий...
Андрей

А ВК объявляет конкурсы по 100 000 руб.

Ответить
Развернуть ветку
Alexey Nekrasov

Бедняга :( Именно это тебя останавливает в них участвовать?

Ответить
Развернуть ветку
Nikolay Kenig

Я не специалист, но у меня вопрос. А что так сложно написать приложение на javeS

Ответить
Развернуть ветку
Mike Espoo

 Сложно.
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 - Все эти конкурсы, это чисто наша тема. Не уважения к труду людей.

Ответить
Развернуть ветку
Maxim Syabro
 2 - Если делаешь продукт на фреймворках, то это жутко не эффективное рассходование средств фирмы и переписывание продукта раз в 5 лет, но так делают все. Плюс весит все это много. Работает по факту медленно, чтобы Вам там не говорили.

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

Ответить
Развернуть ветку
Mike Espoo

О разработке js софта без фреймворков от моего конкурента.
https://realtalkjavascript.simplecast.fm/99e4af34

Ответить
Развернуть ветку
Maxim Syabro

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

Абсолютно разные цели и средства.

Ответить
Развернуть ветку
Mike Espoo

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

Ответить
Развернуть ветку
Maxim Syabro

Ну давайте не будем скатываться до "ой все"

Еще в бородатом 2008 писал энтерпрайз без фреймворков и без jQuery на 40-50 экранов с XML на бекенде.
Потом дорабатывал англичанам их внутреннее решение, тоже без фреймворков.

И за время карьеры писал на Ext.js Backbone, Knockout, Amber, Angular, React, Vue, сейчас ковыряю Svelte и смотрю в сторону Kotlin

Так что имею представление о чем говорю.

Есть куча критериев по которым нужно сравнивать любое решение в разработке. И сорян, но "продукт на фреймворках, то это жутко не эффективное рассходование средств фирмы и переписывание продукта раз в 5 лет" это аналитика уровня /b/

Ответить
Развернуть ветку
Mike Espoo

 Мне не хочется ругаться с Вами на 100 комментов.
Считайте что Вы правы.

Ответить
Развернуть ветку
Андрей Захаров

Бред. Кастомизированное решение под задачу всегда лучше универсального,  а то, что единого универсального на все случаи жизни и времена фреймворка так и не создано - только подтверждают этот тезис.

Ответить
Развернуть ветку
Maxim Syabro

"всегда лучше" - популизм
По каким критериям?

Ответить
Развернуть ветку
Андрей Захаров

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

Ответить
Развернуть ветку
Maxim Syabro

"По-любым" это только "по скорости работы" и то сильно зависит от разработчиков.
Итого из 

- стоимости разработки /скорости разработки
- стоимости поддержки и сопровождения
- скорости работы 

Имеем только последний пункт и то не на 100%

"всегда лучше" ага :)

Ответить
Развернуть ветку
Андрей Захаров

Конечно зависит от разработчиков, иначе из-за чего бы была большая стоимость разработки. Это даже не обсуждается, но я исхожу из потребности. Если деньги на проект есть, то найти качественных разработчиков, которые смогут реализовать все преимущества кастомного решения, не проблема. Собственно, те же самые JS фреймворки когда-то и были внутрифирменной, кастомной разработкой. 

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Сергей Токарев

100 килобайт кода - это не 100 килобайт текста. Это все
- парсится
- раскладывается на AST
- пытается оптимизироваться
- переводится в байткод/подстраивается под конкретный машинный процессор

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

PS: вот
https://habr.com/ru/company/mailru/blog/321748/

Ответить
Развернуть ветку
Mark Rapida Gromov

100кб кода роли не играет? Хорошо, да. Только потом не удивляйтесь, что это «роли не играет» отжирает всю вашу оперативку, забивает проц и вообще загружается через раз

Ответить
Развернуть ветку
Ол Б

Дада, жутко не эффективно:) А переписывать спагетти говнокод за очередным мамкиныным архитектором это выгодно и эффективно? Фреймворки стандартизировали написание фронта и принесли порядок в хаос фронтенд разработки, когда как раньше любая макака писала отсебятину:)

Ответить
Развернуть ветку
Андрей Захаров

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

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

Ответить
Развернуть ветку
Станислав Кукаев

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

Ответить
Развернуть ветку
Nova Vovikov

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

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

Я думаю, что так в любом деле. Всё зависит от того, как заморочиться и сделал максимально качественно.

Ответить
Развернуть ветку
Anton Smets

Как будто фреймворки это что-то плохое, в эпоху, когда 5g на пороге, вы волнуетесь о нескольких лишних мегабайт?

Ответить
Развернуть ветку
Звенислав Николаевич
Ответить
Развернуть ветку
Pavel Zamyatin
Компания учтёт, если сервис получит дополнительные функции, такие как отправка сообщений ...

Отправка сообщений для мессенджера это дополнительная функция?

Ответить
Развернуть ветку
Ватник в Америке

Цель — лёгкий и быстрый интерфейс в первую очередь без фреймворков. Отправка сообщений в твоём проекте это уже опционально и будет типо бонусом/плюсом в принятии решения проверяющими. 

Ответить
Развернуть ветку
Nova Vovikov

Это конкурс и скорее всего то, что ты сделаешь не пойдет на продакшн. Ну или с сильными изменениями.

Ответить
Развернуть ветку
Anton Ivanov

Запилите уже преобразовывание ссылок на телегу на открытие телеги, лень впн подрубать каждый раз

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Dmitry Yankovoy

Тот случай, когда заработать 80 тысяч проще, чем выиграть.

Ответить
Развернуть ветку
Nova Vovikov

Нужно понимать, что эти деньги просто раскидают на всех призёров. В прошлом конкурсе их было овердохера. Но свои 1-2к долларов, может и получишь, если повезет.

Ответить
Развернуть ветку
Dmitry Yankovoy

Тем более

Ответить
Развернуть ветку
Alex Barashkov

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

Ответить
Развернуть ветку
Егор Мышляев

Приложены пнгхи (херовый аргумент, это я просто доебался).
Там есть стайлгайд в файлах (файлик приложил).
Остальное посмотрел и не нашёл стайлгайдов по отступам и цветам. Но в самом соревновании написано: "Почитайте исходный код текущего приложения, окда?", что можно читать как "Ну нам ващет нужны разработчики, которые и без стайлгайда сделать могут что-нибудь. Вот вам код, читайте".
Подход, как минимум, дискуссионный.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Антипов

Телеграм постоянно какие-то конкурсы пилит. Жаль что я не разработчик. Думаю очень интересно создать что-то упрощенное так еще и получить кучу денег за это...

Ответить
Развернуть ветку
Sakari Sauso

У них и для дизайнеров конкурсы есть

Ответить
Развернуть ветку
Evgeni Nabokov

TS можно?

Ответить
Развернуть ветку
Владимир Садовников

Тоже интересно можно ли использовать typescript.

Ответить
Развернуть ветку
Александр Симонов

У них говянное жюри, потому пошли они в жопу со своим конкурсом, ахахаха 🖕

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
38 комментариев
Раскрывать всегда