@tekkie exemplul este complet ortogonal la ceea ce zice @flavius pt. ca este vb. de mai multe platforme i.e. solutia este clara si relevanta in exemplul tau.
Revenind la:
Whatever floats your goat as long as you don’t make it the Savior of all that is programming
Just no.
Am incercat sa gasesc un exemplu din care sa reiese cat mai simplu cine e vendorul si unde e potentialul de lock-in, in ideea in care se dorea o intelegere a conceptului. Gasim ceva mai simplu si mai explicit? Ca ar fi bine sa le avem la indemana pentru viitor, si cu cat e mai complex cu atat e mai greu de explicat. Si nu mi-a venit o idee mai simpla, desi as fi vrut.
Articolul e bun de citit, dar e subiectiv si poate lasa foarte usor o impresie gresita.
In esenta, articolul greseste generalizand prea mult, presupune ca (toata) lumea in general foloseste the wrong tool for the job.
Do I use frameworks? Only when it’s not required to maintain a product in future. But it’s a complete suicide to use them in a service that will live and grow for at least a year or two.
During this time, you will write more code, than that of the entire framework, and face its limitations more than once
Deci toate framework-urile sunt rele, indiferent la ce le folosesti?
In cele din urma, da totusi un exemplu:
But what if I want to fetch Backbone models according to my API, or not fetch them at all? Or maybe I want to get them from the localStorage? What if there’s a complex logic of updates, depending on the date and flags, and we should send a pool of the same model to another server after the fetch? You never know. Should we use Backbone in such situations? There will be only 5% of its functionality. The rest will be workarounds and custom logic.
Asta e altceva totusi, si intr-adevar este wrong tool for the wrong job.
Deci pana la urma nu orice framework e o alegere proasta si de fapt totul tine de context?
In final, a cui e vina, a framework-ului sau a celui care nu a stiut dinainte daca Backbone e bun sau nu pentru ce se implementeaza?
P.S.: The article is intentionally provocative. Of course, frameworks have certain advantages, but still, they cultivate ignorance. It’s a shame when someone can not solve a problem without a framework and gets stuck in work for days and weeks.
E problema fiecaruia in parte ca e ignorant, si nu a framework-ului. Daca tu nu cunosti si nu intelegi design pattern-uri, nu e problema nimani, decat a ta.
Alegerea unui framework pentru urmatorul proiect e o mare responsabilitate.
Cel care o face trebuie sa ai experienta necesara sau daca nu o are, sa petreaca ceva timp studiind framework-ul si scriind cod proof of concept.
I had a job interview for a company in Spain, where I had to finish a test within an hour, in the live-coding mode. The task was to create a single page application for documentation. I performed the task in JavaScript, using module libraries only. I even had time to write tests.
They couldn’t understand how I implemented routing, as well as complex interactive elements, and plenty of other things, without using frameworks. They are the guys who have been in the industry for 10 years, just like me, but they studied specific solutions rather than principles.
Funny, pai exact de asta e bun framework-ul.
De ce ar fi stat angajatorii sa incerce sa-i inteleaga la interviu propriul lui router, cand un framework are deja asta implementat, testat si para testat de ani de zile, si care poate a luat in considerare diverse aspecte pe care propriul sau router nu le-a luat?
Orice framework ia timp ca sa-l intelegi, atat cu rele cat si cu bune. Daca scriem noi framework-ul propriu, altii tot vor trebui sa petreaca un timp intelegandu-l.
Pot fi framework-uri care incearca sa faca prea mult, nu sunt flexibile in a le putea inlocui unele componente cu altceva.
Dar poate chiar si asa, sunt OK pentru unele proiecte, chiar si pentru un proiect mare, la care se dezvolta de-a lungul anilor de catre o echipa.
It’s all about the right tool for the right job.
Generalizarea e naspa.
Depinde de context - in unele cazuri are sens in altele este just because I want to. Nu sunt fan al paradigmei just because I want to. Prefer un refactoring iterativ cuplat de domeniul problemei decat sa pornesc de la ipoteze gresite.
OOP et al nu este ceva fix i.e. there’s no categorical imperative there
Daca vrem ceva apropiat - limbajele “pur” functionale sunt salvarea (Haskell et al).
In plus fata de ce am zis mai sus, e vorba de costuri.
Motivul bun pentru a folosi cand se poate un framework popular in loc sa scrii ceva in the house, e ca cei care sunt angajati noi au lucrat cu acel framework popular si au deja experienta. Nu trebuie sa invete nimic ce tine de framework-ul in sine.
Sunt multe ore in spatele intelegerii corecte unui framework, nu e doar sa stii pe dinafara API-ul.
Dar mai este si faptul ca daca lucrezi doar cu framework-uri “perfecte”, nu ai sansa sa vezi anumite componente gandite gresit si sa intelegi de ce au fost gandite gresit si cum trebuiau gandite.
Ok, poate ca idealizez, dar, after all, omul din greseli in vata, iar de cele mai multe ori sunt greselile proprii. IT-ul pare sa fie o exceptie, si in unele cazuri este, insa exceptia confirma regula, caci doar cei “la un anumit nivel” pot fi numiti exceptii de la regula, si asta fiindca ei deja au fail-uit suficient incat sa inteleaga cum merg lucrurile si sa invete din greselile altora.
Don’t tell me there are more than a few devs who are never twrong…
Nu cred ca exista asa ceva, intotdeauna e vorba de un trade-off, singura problema e cat de mare e.
Deci … cum? 
E vina framework-ului ca e atat de “perfect” incat nu vezi ce e gresit in el !? 
WTF are we talking about… I’m lost
Vreau sa spun ca framework-ul este, deobicei, destul de safe to work with, mai ales pentru incepatori, ceea ce ii pune intr-un mediu lipsit de probleme de securitate, care le da voie sa nu fie preocupati de cat de sigur este codul scris de ei.
Stiu ca poate nu are sens ce spun, insa am gandit-o ca o paralela la a fi tinut intr-un mediu steril, cand esti mic, face ca atunci cand cresti sa ai probleme cu imunitatea. Dar more programming-ish…
Pai exact asta e unul din rolurile unui framework. Te ghideaza in directia buna, si te obliga sa faci unele lucruri cum trebuie, fara ca tu sa stii de ce o faci,.
Faptul ca tu nu stii de ce faci anumite lucruri intr-un fel anume, e numai problema ta. Poti pune mana pe carti si studia design pattern-uri, si poti studia chiar codul sursa a framework-ului, daca vrei.
Daca apoi, o data cu experienta, iti formezi o parere ca anumite componente dintr-un framework nu functioneaza cum ai vrea, sigur, poti sa incerci sa schimbi asta. Poate iti dai seama ca un framework e mai bun ca cel care-l folosesti, si-l schimbi cu totul.
E evident ca nu are nici o legatura daca cel care il foloseste e incepator sau senior.
Daca esti senior nu inseamna ca nu e de nivelul tau sa folosesti un framework, e o idiotenie.
Eu unul sunt uimit ca exista atat de multe discutii pe tema asta, dar asta probabil ca nu prea am exercitiul forum-urilor de ceva vreme.
Rar citesc prostii mai mari despre software. Pe lângă faptul ca are un ego incredibil de mare, mi se pare ignorant sa zici chestii de genul
We all know that Angular has a lot of problems, and debugging is one of the main ones.
No, we don’t all know that.
When undocumented errors occur, only stackoverflow can save us.
Serios?! Da undocumented errors cum se rezolva în alte tehnologii? Stackoverflow.com e pentru nobi, nu?
To create classes, I use a library written 5 years ago.
JS nu are clase (inca), e un antipattern, scrisa de oameni ce vin din Java world. Prototypes man, no library.
Pe lângă logica greșită folosita, tipul greșește din principiu. Nu e normal sau recomandat sa faci totul de la zero.
Ah, acuma vad ca “The article is intentionally provocative”. Got me 
Tu parca ești WordPress dev, nu? 
De ce ar fii JS framework mai special decât php framework?
Sunt conștient de limitările impuse de WordPress și nu îmi amintesc să fi spus vreodată că WordPress este răspunsul întrebării supreme despre viață, univers și restul 
ES6 are clase, nu? Chiar daca e doar syntactical sugar
Dar nu pricep de ce crezi ca nu ar trebui folosit un framework. Tot ce te plângi, ca maintenance, ca documentație, se aplica și la cod scris custom. Sau ai impresia ca toți developerii scriu documentație mai buna?
Uite exemplul de router scris de OP. Se mândrește ca nimeni nu pricepea cum l-a scris fără framework. Ți se pare mai ușor decât dacă scria într-un format standard la un framework, ce e sigur documentat?
Și am menționat WordPress fiindcă nu recomanzi un framework JS. Dar (presupun) ca recomanzi ca un website sa fie scris in wp?
De-aia am zis “încă”.
Eu nu as scrie cod de producție în ES6 azi. Poate mâine.
Dar recunosc ca folosesc typescript ceea ce într-un fel ma face es6 dev
Care e deosebirea intre a folosi ES6 sau TypeScript azi, nu ambele folosesc transpilers?
Typescript e compiler, ES6 e JS pur, un standard care ajunge în browsere nativ încet încet.
Ăla e rolul unui framework pentru programatorii mediocri, nu pentru cei sănătoși la cap.
Si pentru cei “sanatosi la cap”, de ce nu ar fi si asta rolul unui framework?
Să îi facă mai productivi, fără vendor lock-in.