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

начитался о prototype но не могу придумать куда его на практике применить
встретил такое, но по моему только лишний код, проще функции вызывать

var mainPage = null;
$(function(){
  mainPage = new CMainPage();
});

var CMainPage = function()
{
  this.init();
};

CMainPage.prototype.init = function()
{
  this.initSlider();
};

CMainPage.prototype.initSlider = function(){
...
}

чем это лучше такого?

$(function(){
  initSlider();
});

initSlider = function(){
...
}

может памяти меньше занимает т.к. функии в одном объекте или ещё что

реквестирую пример использования prototype из реальной практики по работе с DOM, где обычно нужно что-то скрыть/показать/переместить...

ты вообще понимаешь что такое ООП?

да, не понимаю как этот подход применить к управлению DOM

я вот тоже не понимаю каким образом обьектно ориентированное программирование основанное на прототипном наследовании ВООБЩЕ связанно с работой с DOM)

можно же обработку событий добавлять через прототипы, но не пойму зачем) а в учебниках примеры с птичками и партами

animhotep,
К примеру добавить какой нибудь метод для работы с элементом. Допустим добавить в прототип метод hide() скрывающий элемент и тогда можно будет любой элемент скрыть вызовом

el.hide()

Или допустим напишешь метод ajaxReload() который при вызове обновляет содержимое элемента данными с сервера

el.ajaxReload()

. Удобно однако :)
В общем прототип это объект содержащий методы и свойства доступные тем кто его наследует. Эти методы и свойства создаются только один раз а значит потребляется меньше памяти чем если бы ты в каждый объект добавлял аналогичные методы или свойства.

я вроде понял что он такое и как работает..
а можно написать функцию hide = function(el){}, и вызывать hide(el)

Конечно можно. Но зачем засорять область видимости специфичной функцией? К тому же прототипы удобнее и нагляднее использовать:
По твоему методу

hide(document.getElementById('some'));

С прототипом

document.getElementById('some').hide();

PS
Когда только начал использовать JS тоже противился прототипам, но после прочтения Флэнагана и JavaScript Шаблоны понял всю мощь и удобство их использования.

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

это она? http://www.ozon.ru/context/detail/id/3881091/ у меня следующая на очереди прочтения, может после неё дойдёт)

Да, она. Только есть более новая 2012 года.
JavaScript Шаблоны описывает лучшие практики работы с JS.

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

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

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

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

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

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

Другими словами если человек запихивает всё в (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();
    }

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

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

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

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

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

откуда у вас такое пренебрежение к самовызывающейся функции?

от нубства

А с чего вы взяли, что у меня к таким функциям пренебрежение?