The no framework JS framework

From some time (2+ years) we can observe a huge explosion of different  Javascript frameworks. These frameworks divide mainly into two categories

  1. UI widgets / DOM manipulation frameworks
  2. class based type system frameworks

In this post I would like to focus on the latter. Every time is see a new framework of this type popping on the news I tend to ask myself the same question – why ? Why one does write all does frameworks, why people so much need classes in Javascript ?

After some thinking I’ve got to a conclusion, that people need them mainly because they are used to the concept of the „class” and to a typical type system like this found in Java, PHP or „name your favorite mainstream programming language here”. This is understandable, as naturally human beings are resistive to change.  Also, some people tend to „not get” what’s going on in the prototypical type system. We cannot also blame them here because it has  some quirks and well, no one teaches it in schools ( ;P ).

One may ask himself – do we have an other choices to write clean, readable and understandable code other than using JS frameworks ? I think the answer for this question would be affirmative.

But before we come up for a solution. We must think for a second and summarize what we are trying to achieve. I think that are needs wrap in:

  1. new object instantiation
  2. information hiding
  3. code reuse
  4. modularization

The thing that some one will miss would be inheritance. Should it be on the list ? I don’t think so. The reason for the lack of inheritance is simple – inheritance has two purposes:

  1. vertical code reuse – the type lower in the hierarchy inherits behavior from the type higher in it
  2. signature checking – in statically typed class based languages, polymorphism is achieved through inheritance

we could achieve code reuse by other means in Javascript and as JS has no type checking we don’t need inheritance at all.

For our „no framework JS framework” we will use mainly such features of JS as first class functions and JSON. So behold, some common patterns for our daily JS programming:

Usage of the example:

The first example proves, that we can achieve all of our goals through simple Javascript, without the need for frameworks. The additional benefit is that, because all is private by default, we improve the „cleanliness” of our API.

  1. wookieb pisze:

    Brak sprawdzania typów = bardzo łatwa możliwość stworzenia śmietnika/miszmaszu, czyli rzeczy niezwykle nieporządanych.
    Sprawdzanie typów (szczególnie dzięki ecmascript 5) ma sens i każdy programista (nie koder) to wie. Rozumiem twoje podejście aczkolwiek dziedziczenie prototypowe to wcale nie jest taka zła rzecz :)

  2. @wookieb: nie krytykuje w żaden sposób podejścia prototypowego, sposób pisania kodu jaki przedstawiłem moim zdaniem po prostu bardziej przemawia do programistów, którzy nie są z nim obeznani, co do sprawdzania typów to oczywiście jest to fajny feature, natomiast dopóki wszystkie popularne przeglądarki nie będą obsługiwały typowania argumentów funkcji to generalnie jest to mało przydatny ficzer

  3. wookieb pisze:

    Ale aktualnie w js nie ma typowania argumentów. MIałem na myśli możliwość sprawdzenia takowego już w samym kodzie funkcji (wiem, że przedpotopowe ale lepsze niż nic).

    Twój przykład nie przypada mi do gustu właśnie z powodu niemożliwości sprawdzenia skąd „w rzeczywistości” pochodzi ten obiekt. Można powiedzieć „hole hola, przecież w js można wszystko zmienić”. No już nie do końca.
    Dzięki EcmaScript5 i deskryptory jest możliwe zablokowanie zmiany pewnych właściwości (m.in obiektu Window) do tego stopnia, że typowanie zaczyna mieć naprawdę sens.

  4. Raynos pisze:

    > The thing that some one will miss would be inheritance. Should it be on the list ?

    Yes and it is on the list it’s called prototypes.

    What you have shown is a generic manual object construction mechanism through closures which is acceptable but has performance penalties.

    Generally you would want to use prototypes instead.

  5. @Raynos:

    I know the drawback’s – for example, every time, you invoke the constructor the methods are created anew. Anyway, I don’t state that this method of doing „OO” is the best, but as I said, if someone doesn’t understand prototypes, then he could use the shown method instead of using some heavy JS framework, which will also have a performance hit. Maybe it is a good topic to write a new post – a comparision of the presented method and some mainstream JS frameworks.

    … and about the inheritance, I’m not a big fan of it, and in Javascript, where you don’t use polymorphism, you have other means to achieve code reuse.

  6. Raynos pisze:

    @Wojciech

    You make it sound like you can either use closures or use heavy javascript frameworks. There’s the third alternative of learning prototypes.

    And in javascript you do use polymorphism. There are indeed other means of code re-use (composition) but inheritance is a powerful tool that shouldn’t be _ignored_

    Oh and I refactored your code using OO (and a small utility called pd) : https://gist.github.com/1393837

  7. @Raynos

    I didin’t mean to sound it like that, what I wanted to say was that, that if someone doesn’t understand prototypes, he could choose this option. But of course, learning prototypes would be the best way after all, as this is the native JS approach.

    The refactored code looks quite clean.

    Btw. I don’t actualy get your point about polymorphism, as JS doesn’t have typed arguments. Maybe you are reffering to duck typing, could you clarify this point ?

  8. Raynos pisze:

    @Wojciech

    > polymorphism

    Polymorphism simply means that any function which expects type X can take any object which inherits from type X.

    So if you have a Person [[Prototype]] and you let FitnessAddict by a [[Prototype]] that inherits from it.

    Then any function which expects an argument with [[Prototype]] === Person will work with an argument whoms [[Prototype]] == FitnessAddict.

    This ties in with duck typing. We are doing polymorphism by defining an interface (in your head / documentation) that a function accepts. And the fact that as long as an object implements that interface it will work is what it means to do polymorphism

  9. @Raynos

    Duck typing is a bit different concept than polymorphism. With duck typing you don’t care about the object type, until it behaves according to some contract (for example defined as a set of unit tests). So in case of Javascript, we could tell, that the language supports duck typing, because you can write an application, that does not check for specific types, and just assumes that some object has some method.

    With polymorphism, the only way you can enforce types is via the instanceOf operator or isPrototypeOf function, with the latter checking the whole prototype chain. So I would tell, that Javascript supports some form of prototypal polymorphism, although very different from the class based polymorphism that we know from a classic (java/c++) like oop model.

  10. Raynos pisze:

    @Wojciech

    I think were fighting over terminology here.

    What do you think polymorphism means?
    What do you think duck typing means?

    I personally think that duck typing is a polymorphism mechanism, so duck typing -> polymorphism.

    Polymorphism has nothing to do with type checking for me.

    I wrote a stackoverflow question about what’s „correct” : http://programmers.stackexchange.com/questions/121778/is-duck-typing-a-subset-of-polymorphism

  11. @Raynos

    I dont fight over anything. I just think that these are two different concepts which have a similar effect. It is as a train and a car, both serve to get from point A to point B but work in a different way.

  12. aeeo43534 pisze:

    To Pana dzieło?

    http://helion.pl/ksiazki/programowanie-w-jezyku-scala-od-podstaw-wojciech-soczynski,prscal.htm

    Ach te polaczki zwalają z zagranicznych książek i potem wydają pod swoim nazwiskiem???

    Na amazon.com jest książka o Scali napisana przez samych twórców języka więc nie kupie tego gniota z helionu.

    Programming in Scala: A Comprehensive Step-by-Step Guide, 2nd Edition
    Martin Odersky

  13. @aeeo43534:

    Tak, to będzie moje dzieło. Nie rozumiem Pańskiego negatywnego podejścia. Nikt tu nie zamierza „zwalać” z zagranicznych książek. Co więcej, mam nadzieje, że uda mi się zaprezentować świeże podejście do niektórych tematów. To czy książka będzie gniotem, czy nie, to ocenią już czytelnicy.

  14. bumelant pisze:

    Bardzo ładne daje świadectwo kolego o sobie. Nie widziałeś nawet spisu treści a już piszesz że gniot. Ach te polaczki, zamiast się cieszyć że community Scali rośnie w siłę to byle tylko ktoś się nie wychylił. Nie ma się co dziwić że nie mamy żadnego naprawdę znanego projektu open source.

  1. […] [repost ]The no framework JS framework  JavaScript  Add comments Nov 262011   reddit_url = "http://blog.newitfarmer.com/programming/javascript/4216/repost-the-no-framework-js-framework/";reddit_title = "[repost ]The no framework JS framework";reddit_newwindow="1"; original:http://blog.wsoczynski.pl/2011/11/22/the-no-framework-js-framework/ […]

Leave a Reply

Informuj mnie o odpowiedziach poprzez e-mail. Możesz również subskrybować wpis bez zostawiania komentarza.