prototype в реальной жизни

[jsgeek]

если дело только в именах то мне их не жалко)

то как js программист относится к глобальному объекту говорит о его профессионализме. Чем выше уровень тем меньше глобальных переменных

[animhotep]

о, благодарю. буду читать дальше
пока для себя вижу только одно преимущество прототипов - меньше глобальных переменных, но мне они никогда не мешали

кошерность кода для меня не важна на данном этапе. я думаю функциями и мне их легче читать

[danik.js]

Удобно пока не появятся hideLightbox(lightbox), hideBlock(block), hideAnotherThing(anotherThing) вместо удобных lightbox.hide(), block.hide(), anotherThing.hide()
И вобще, почему свойства объекта должны быть в объекте, а методы объекта должны быть в оторваны от него? Подобная хрень наблюдается в php с его str_replace'ами всякими и array_combine'ами и жутко бесит )
И еще: допустим внутри метода нужно вызывать другой вспомогательный метод - как ты это разрулишь?

[animhotep]

внутри метода нужно вызывать другой вспомогательный метод

вроде как ничего не мешает функцию в функции написать

пример бы... в котором явно видно преимущество прототипов, я почему то таких не встречал пока

[ILL-JAH]

то как js программист относится к глобальному объекту говорит о его профессионализме. Чем выше уровень тем меньше глобальных переменных

Другими словами если человек запихивает всё в (function(){})(), то он гуру js?

допустим внутри метода нужно вызывать другой вспомогательный метод - как ты это разрулишь?

Может так?:

var clsCreateUser = function (name)
    {
      this.name = name
      this.change = function () { document.getElementById("uName").textContent = this.name; }
      this.edit = function ()
      {
        this.name = document.getElementById("edtName").value;
        this.change();
      }
      document.getElementById("edtBut").onclick = function () { clsCreateUser.user.edit(); }
      document.getElementById("delUser").onclick = function ()
      {
        delete clsCreateUser.user;
        document.getElementById("uName").textContent = "";
      }
      this.change();
    }

[ILL-JAH]

я думаю функциями и мне их легче читать

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

[danik.js]

Если в решении задачи лучшим является функциональный метод

Так javascript насколько я знаю пропитан функциональностью. О чем говорят методы call() и apply() . Да и классов в нем нет.
Пока нет наследования и конструкторов - нет никакой разницы.
Сейчас мы видим детский сад. Там можете играться чем угодно.

[jsgeek]

Другими словами если человек запихивает всё в (function(){})(), то он гуру js?

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

[ILL-JAH]

Вобщем, кому охота прокачать свой скилл в прототипах - читаем книгу: Алекс Маккоу "Веб-приложения на JavaScript" (2012).

[jsgeek]

Вобщем, кому охота прокачать свой скилл в прототипах - читаем книгу: Алекс Маккоу "Веб-приложения на JavaScript" (2012).

Я эту книгу не читал, но мне казалось там описывается использование MVC в JS, а заметка на обложке гласит - "Для jQuery-разработчика", что вероятно подразумевает знание jQuery.