Imi place Bootstrap si cred ca e cel mai bun lucru care a aparut pe webdev de la … Firefox incoace.
DAR.
Politica la versiunile noi mi se pare extrem de agresiva, backwards compatible mai deloc, renunta la chestii care se folosesc, schimba denumiri, clase. Basically e greu sa faci update la o versiune majora. Fie iei la mana toata aplicatia sa inlocuiesti / schimbi pe unde au modificat, fie nu faci update. Am aplicatii pe Bootsrap 2 la care nu pot face update, am toate pe bootstrap 3 la care nu pot face update. Ok, astept sa inceapa un proiect nou sa pun 4, dar n-am proiecte noi asa des. Or daca intretii o aplicatie pe termen lung, te simti left out.
Cum as face eu: la versiunile noi as oferi si niste fisiere care sa ofere macar functionalitate la elementele schimbate de la versiunea trecuta, alias-uri, css etc.
Inteleg ca e munca in plus si e greu, insa nu ma vad vreodata facand update la Bootstrap in vreun proiect.
When we shipped Bootstrap 3, we immediately discontinued all support for v2.x, causing a lot of pain for all our users out there. That was a mistake we won’t be making again. For the foreseeable future, we’ll be maintaining Bootstrap 3 with critical bug fixes and documentation improvements. v3 docs will also continue to be hosted after v4’s final release.
Nu am facut migrari majore, aplicatii complexe, dar cand am facut m-am folosit de IDE si refactor/rename in tot proiectul utilizand http://getbootstrap.com/migration/ apoi la ce s-a renuntat am refacut fie prin copierea css-ului din v2 pt elementele respective fie prin scrierea altui css. Unde aveam css suprascris, la fel, refacut/ajustat dupa caz. Nu e un job usor dar e realizabil.
Oricum, cu rapiditatea cu care se schimiba versiunile majore nu o sa poti mentine o aplicatie prea mult timp up to date. Bootstrap, Angular sunt doar doua exemple. Sper ca angular 2 va domni mai mult timp decat v1. Pana la urma, daca e vb de munca prestata pentru client, migrarea o faci contra cost, e alegerea lui. Doar din frecvente incrementari majore ale versiunilor te poti asigura ca faci acceasi aplicatie de mai multe ori, incasezi de mai multe ori. Uite asa se creaza mai multa cerere . Frustrant e ca pana faci 1-2 applicatii te inveti cu libraria si poti sa te lauzi ca o stapanesti si ca productivitatea ta e mai mare, si iar trebuie sa o iei de la capat cu versiune noua…
Imi imaginez ca esti programator, de asta gandesti asa.
BC-breaks fragmenteaza comunitatea (vezi python 2 vs 3)
pt un business (care in general nu inseamna “tech people”), schimbarile bruste inseamna bani cheltuiti. Un update fluent este de dorit - de ambele tabere. Daca business-ul nu isi updateaza produsele, si vendorul pierde bani, iar business-ul ramane cu un produs depasit (probleme de securitate, bug-uri etc.).
cand scrii software care vrei sa dureze cativa ani (sau decenii, corporate-wise), prioritar e BC (vezi Windows; de ce crezi ca Mac este practic inexistent in lumea corporatista?!).
In afara de prima, poate celelalte se aplica mai putin unui frontend fw, dar e un inceput. Web dev-ul se misca foarte repede (fucking javascript…), de asta gandim asa.
cand scrii software care sa tina decenii iti asumi niste riscuri. softul tau va fi depasit in maxim 2 ani. trendurile apar si dispar foarte repede. azi merge php. maine o sa mearga node. poimaine o sa mearga bitzard. nu-i logic sa te vrei sa mentii o bucata de cod la zi. ai bs1 si vrei sa treci pe 3? proiect nou pe frontend. ai php3 si vrei sa treci pe php7? proiect nou pe backend. nu vrei sa dai bani? ramai cu acelasi soft. faptul ca-i invechit nu inseamna ca nu mai merge. nu-i normal sa tii tehnologia in loc doar pentru ca vrei compatibilitate pe niste proiecte depasite la 3 zile dupa ce le-ai finalizat.
ps: windows e alta mancare de peste. microsoft e obligat sa incerce sa mentina compatibilitatea ca sa poata vinde versiuni noi. dar noi vorbim de limbaje de programare/frameworkuri. alea au obligatia sa avanseze.
Cand folosirea unui software iti creste costurile cu mentenanta si dezvoltarea, te gandesti de 2 ori daca il mai folosesti. Fix ca la Windows. Daca la fiecare versiune de win trebuia sa cumperi alte softuri, mai faceai update?
Deciziile tale cu privire la backwards compatibility afecteaza costurile celor care iti folosesc softul. In mod direct.
Nu văd neapărat unde e problema, nu spune nimeni că trebuie să fii mereu la zi cu toate componentele folosite. Atâta timp cât aplicația merge nu ai niciun motiv să te apuci să faci upgrade-uri în afară de situația în care vorbim de securitate sau că vrei să reinventezi roata, dar nu văd cum un upgrade de la, să zicem, bs2 la bs3 îți face aplicația semnificativ mai bună cu ceva, mai ales dacă ai mai și customizat css-ul ăla și nu arată stock.
A, că tu te simți „left out”, deși sună puțin dur, asta e fix problema ta și nu înseamnă că se justifică investiția de resurse, atât din partea dezvoltatorilor (care oferă un tool gratis), cât și din partea clienților (pe care de obicei îi doare la patină dacă folosești bs2, bs3, bs5 sau altceva)
vorbim de un framework. o colectie de scripturi care te ajuta sa scrii soft. un framework care-i gratuit. nu te obliga nimeni sa-l folosesti. o sa vina altii care o sa-l foloseasca.
atitudinea? adica tu te folosesti de munca lor si tot ei au obligatii fata de tine? pe bune? poate ne explici si noua ce le iese lor ca tu le folosesti frameworkul de ar trebui sa se simta obligati.
Pai cred ca Bootstrap e folosit un pic incorect de majoritatea utlizatorilor. Nu este o tema Wordpress, ca sa ii faci upgrade din 2 click-uri.
Pentru un aplicatia mai mare eu am luat less-urile din Bootstrap si am inceput sa ma joc cu ele. Prin variables.less am modificat tot ce tinea de proiect, din bootstrap.less am comentat ce nu foloseam (bootstrap.less are doar import-uri in el). Dupa ce am facut treaba asta e cam clar ca nu aveam nici o sansa mai fac upgrade, indiferent daca developerii aveau un upgrade path clar si relativ usor.
Bootstrap al trebui sa fie un punct de plecare, care sa te scuteasca de niste munca, nu sa fie folosit ca o tema de CMS. Si cred ca asa vad si ei lucrurile si de aici si lipsa unui upgrade path sau a backwards compatibility.
Easy now. stau acuma sa-ti explic cum e cu open source-ul? daca voiau sa le iasa ceva, il faceau pe bani. Acum vand teme vad, deci abia de-acuma incolo poate le iese si ceva. Si se bazeaza doar ca are succes fix datorita faptului ca a fost free si open si nu le iesea nimic.
Oh… Eu am încercat să folosesc o singură componentă js: carousel. Buggy, greu de customizat, greu de suprascris defaults (e.g. dacă vrei un alt efect în afară de slide-ul ăla you’re fucked) și, bonus, nu știe de swipe by default. Ceea ce mi se pare extrem de stupid pentru un framework ce se laudă a fi mobile first…
Dacă stau să mă gândesc, singurele componente folosite constant din BS sunt gridurile (o versiune modificată din care am tăiat tot codul inutil și am adăugat mici chestii de care am tot avut nevoie) utilitarele de vizibilitate (e.g. visible-xs & co) și formularele (întotdeauna am urât să fac formulare).
Până acum n-am întâmpinat probleme (bine, nici nu am început să folosesc de la v2.0.0; probabil primele 2-3 versiuni minore sunt mai buggy).
. Frustrant e ca pana faci 1-2 applicatii te inveti cu libraria si poti sa te lauzi ca o stapanesti si ca productivitatea ta e mai mare, si iar trebuie sa o iei de la capat cu versiune noua…
stau acuma sa-ti explic cum e cu open source-ul? daca voiau sa le iasa ceva, il faceau pe bani. Acum vand teme vad, deci abia de-acuma incolo poate le iese si ceva. Si se bazeaza doar ca are succes fix datorita faptului ca a fost free si open si nu le iesea nimic.