На каком языке\и каком фреймворке языка лучше написать онлайн-доску? Что-то типа MIRO, или chattern, или sBoard?

Question

[MarinaQA]

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

Подскажите, по какому пути идти, с чего начать?

html, css, база js имеется. Немного могу на python и php
Что нужно изучить чтобы написать онлайн-доску?

Answer 1

[Михаил Р.]

Я ещё не пробовала react. Некоторые говорят на нём писать, некоторые на чистом js.

Вначале на чистом js, затем идите в react, если захотите остаться на фронте.

Что нужно изучить чтобы написать онлайн-доску?

Рисование фигур

Немного могу на python и php

Python/php в "рисование на фронте" не очень помогут.

Comments

[MarinaQA]

Не прогорю ли на самом JS писать?

Если это самый лучший вариант для самообучения, то буду пробовать так

[Михаил Р.]

MarinaQA,

Не прогорю ли на самом JS писать?

Начинать лучше с ЯП, а затем идти в его фреймворки. И что значит "прогорю"?

Answer 2

[Ivan Bogachev]

Что-то типа MIRO или chattern

Это два совершенно разных инструмента.

Подскажите, по какому пути идти, с чего начать?

Как и в любом проекте - нужно начать с составления конкретного подробного ТЗ. Произвести анализ конкурентов. Сформировать требования для MVP. Описать сценарии использования. Проанализировать перспективы развития. Оценить ресурсы. Спроектировать систему на самом верхнем уровне. Потом уже смотреть, какие там инструменты на местах подойдут. Причем вероятнее всего реальные сложности начнутся совсем не там, где вы их сейчас ожидаете. Например бесконечный холст для рисования приведет вас к тому, что нужно уметь работать с канвасом и разбираться в алгоритмах рендеринга и оптимизации всего. Это знания в каком-то смысле параллельные языкам и фреймворкам. А если углубляться в функционал того же MIRO, то, скажем, рисование UML-диаграмм потребует разобраться в самой предметной области, в базовой работе с графами. Или, собственно, онлайн. Нужно чтобы это в реальном времени транслировалось? Нужно совместное редактирование с возможностью сделать ctrl-Z? Тут может вырасти целая карусель из сокетов, системы контроля версий и механизмов синхронизации всего. Конкретные языки там - дело десятое. А вот архитектура проекта в целом может быть реально замороченной. Онлайн-доска - понятие очень растяжимое. Много нюансов, про которые лучше подумать заранее.

Comments

[MarinaQA]

Спасибо за ответ. Хочется от простого к сложному. В начале сделать что-то элементарно, например возможност писать пером на холсте, а затем это все улучшать, дорабатывать, изучать необходимые инструменты для этого. Для САМООБУЧЕНИЯ и планируется.

[Ivan Bogachev]

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

Как маленький локальный пример: сейчас вы задаетесь вопросом, а нужен ли условный реакт? Или не нужен? Может без него будет очень сложно? А может наоборот он усложнит жизнь на ровном месте? А кто ж его знает. А решение это в перспективе сложно поменять. Если бы было ТЗ, то мы бы посмотрели на него и сказали, что, например, интерфейс статичный (шаблонизатор на клиенте не нужен), состояние интерфейса по сути одно (глобальное хранилище состояний не нужно), страница одна (роутер не нужен), и.т.д. Какие-то классы инструментов в этом проекте не нужны. Под них задач нет. Мы придем к выводу, что никакой реакт там не нужен (если грубо говорить, то все фреймворки этого класса - это комбайны из шаблонизатора, роутера, хранилки состояний и еще нескольких связанных штук). А может наоборот, мы посмотрим и увидим, что там все это нужно. Мы не будем гадать на кофейной гуще и чьих-то мнениях. Это будет осознанный выбор инструмента под задачу.