Постараюсь объяснить несколько моментов, надеюсь будет понятно))
Походу получился сумбур
Делал кучу своих велосипедов, все говорили зачем делаешь и чем больше мне это говорили тем с большим усердием я их делал, потому что не нравятся все библиотеки, фреймворки которые есть.
Нравятся определенные моменты, но нет реально либы на которой хотелось программировать.
Когда начал делать свое, понял что у меня получается по сравнению с уже существующими в разы хуже
1 - куча ошибок, не возможно на этом работать
2 - синтаксис ....
3 - никому не нужно
4 - денег на этом не сделаешь
И в итоге понимаешь, в других библиотеках сделано плохо не потому что люди не умеют программировать, а потому что это очень сложно сделать так, чтобы продукт был классным.
5-7 раз начинал с нуля...
Чем больше стараешься - понимать как работают другие библиотеки изнутри.
Еще один момент, исходники проектов, того же JQuery, Angular и прочих помогают лучше понять JS.
Но если тебе проект нравится, то начинаешь в этом стиле писать код.
Стиль кода, тоже очень важная штука.
Не помню как называется, вроде guideline code style.
За многие годы пришел к определенному стилю кода.
Каждый разработчик приходит к определенному стилю.
Но есть стиль разработчика, а есть классический стиль кода.
Постараюсь объяснить.
Это как Венгерская нотация.
Приведу самые элементарные примеры.
Про camelCase уж писать не буду))
Твой стиль - это perl.
Не будут люди пользоваться продуктом если там
my_cool_function для js.
Еще пример
//Bad
if(n)
a = 5;
//Good
if(n){
a = 5;
}
К сожалению в таком стиле до сих пор программируют.
Нельзя.
Ошибок дает кучу.
Случайно добавил лишнюю строку - 2 дня ищешь ошибку.
А еще снижает читабельность.
Во многих вакансия написано:
Умение понимать чужой код.
Умение писать структурированный код.
Потому что хороший код, повышаешь кпд разработки, особенно командной.
Еще пример
//Bad
var a = 5;
var b = 7;
var c = 10;
У тебя в такой стиле все примеры.
Далее использование спец символов.
Давай вспомним для чего используется символ _ перед названиями переменных/свойств.
Для того чтобы сказать, что это свойство или метод private.
Надеюсь не перепутал...
Короче пользоваться исключительно внутри фреймворка, библиотеки.
Не используют в API названия с _, есть такая договоренность.
А вообще я бы советовал стараться никогда не пользоваться _
сразу снижает читабельность кода.
лично я пользуюсь _ только в самом крайнем случае.
Идем дальше.
У тебя пишется Extends
С твоих слов ты взял это из MooTools
Почему так сделали MooTools - потому что слово extends зарезервировано.
В данном случае лучше просто extend.
MooTools классная штука.
Но это не означает, что они все делают правильно.
Они многое делают так, что никто не будет пользоваться им.
Например: глобальные переменные, добавление в глобальные прототипы функций.
Вот если бы они Class, сделали не глобальным
А хотя бы Mt.Class
И не делали
Array.implement('limitTop', function(top){
for (var i = 0, l = this.length; i < l; i++){
if (this[i] > top) this[i] = top;
}
return this;
});
[1, 2, 3, 4, 5, 6].limitTop(4); // returns [1, 2, 3, 4, 4, 4]
А сделали вот так
Mt.Array.limitTop([1, 2, 3, 4, 5, 6], 4);
То даже я задумался про MooTools в реальных проектах.
Теперь про названия свойств
Это что за жесть...
this.Text$broadcastInDOM();
var element = this._input_container.getDOMElement();
И это даже не внутри библиотеки, а реальный код примера.
Очень многие библиотеки имеют плохой API.
Но у тебя API пока, ну сам понимаешь...
Работа над API - не простая штука.
Но API должно быть красивым.
Про то что ты сможешь кому-нибудь это продать.
Я бы сказал так.
Не знаю кто-ты, откуда.
Предположим ты студень на 4 курсе.
Скорее всего(в самом лучше случае) тебе предложат работу, в mail, возможно в иностранной фирме.
Возможно получится на своем продукте что-то сделать.
Конечно это самый идеальный вариант.
Но унывать тут не надо, если нужны деньги, то просто иди на работу
пробуй себя в js в Москве.
Или же может в будущем как Дмитрий Сошников будешь работать в FaceBook
Понимание как писать JS SDK, библиотеки востребовано.
