To hype or not to hype (or why and what hype should you follow)

Moving to current days, the amount of new JS frameworks, tools, packages, transpilers and new lexicon (referring to transpilers) is just too much to handle. A lot of noise and hype you have to move through. Still, some of the things work. jQuery worked. Knockback worked, Backbone.js worked, Angular worked and react.js seems to work. We have to decide carefully what train to jump on and when to leave.

Not jumping on the current tech (=or hype) might be costly

Mi se pare mai interesant citatul ăsta:

We shouldn’t jump on new hype just because it’s new and people are talking about it in meetups. What we should do is learn, understand & experiment. I don’t want to be stuck again in a decade old framework nobody talks about or wants to work with.

Doar din lumea JS, avem: YUI, ExtJS, Moo Tools, SproutCore; care chiar dacă au avut un oarecare succes, acesta a fost destul de limitat.

Cu legătură:

1 Like

@iamntz, te-am vazut de mai multe ori ca ai zis despre chestia asta.
A nu se confunda faptul de a trece pe ce este nou, doar din cauza ca este nou si lumea vorbeste despre asta cu faptul de a trece pe ce este nou, din cauza ca este bazat pe tehnologii noi, mai bune decat cele actuale. De.exemplu, odata cu lansarea HTML5, si a Web Workers, Web Sockets etc. mi se pare logic sa ne mutam pe framework-urile care implementeaza aceste noi tehnologii.

Asta daca e musai sa folosesti un framework. Dar framework-urile sunt pentru prototying, in principal. Daca vrei un long-lasting product, faci totul nativ / vanilla, ca sa intelegi tu cum merge si sa nu-ti pui piedica singur… fiindca, in tinp, framework-ul devine technical debt…

Related:


Nu stiu de ce asociezi techinal debt cu framework-urile. Cred ca incurci un pic. Din contra, daca nu se foloseste framework, probabilitatea de technical debt, e mai mare.

Si, tu ce propui, sa reinventeze fiecare roata? Sa faca fiecare, singur, de la inceput, implementarea pentru diferite chestii?

Sa reinventezi roata (si un simplu copy paste doar la ce te intereseaza e tot reinventatrea rotii) de fiecare data cand stii ca proiectul respectiv o sa aiba durata de viata mai mare de 5 ani… si este prone to changes…

Si chiar daca scrii vanilla, codul ala nu tot devine outdated? Orice cod trebuie intretinut permanent, sau de facut refactoring o data la x ani, dar probabilitatea sa ai tu timp, este mai mica, decat sa aiba comunitatea unui framework timp, sa intretina acel cod.

Si daca framework-ul schimba schestii si cine preia mentenanta modifica chestii aiurea, sau nu modifica chestii atunci cand se face update la framework? Ajungi sa ai api-ul framework-ului sa fie apelat ca si cum ar fi o versiune mai veche a api-ului, rezultand in posibile pierderi de vieti omenesti (in functie de ce face aplicatia)… Ok, poate exagerez un pic, dar pe langa asta, consumi mai putine resurse… si la 30m rulari zilnice ale aceleiasi aplicatii de pe serverul tau, o sa simti diferenta…

Nu cred ca are rost sa ducem discutia mai departe, din cate se vede suntem amandoi rigizi.
Apropo, vezi ca ai scris “umpic”, te-am corectat o data si ai zis ca a fost o coincidenta. :wink:

1 Like

@GarryOne: Pentru că nu o dată s-a întâmplat să mi se ceară lucruri doar pentru că erau la modă/se discuta despre ele, fără ca discuțiile respective să fi fost susținute de altceva decât de hype.

@Sapioit: Dacă nu vorbești din experiență, cred că ești umpic prea entuziasmat. În aplicațiile reale s-ar putea să nu ai 30m (presupun că e vorba de milioane?) rulări/zi (sau ~3500 rulări/secundă).

2 Likes

Fixed.

@iamntz Aici asa este. Majoritatea aplicatiilor sunt sunt rulate de clienti… dar mai sunt si situatii gen facebook unde, daca ai inceput cu un frameword, s-ar putea sa trebuiasca sa renunti la el destul de curand…

Eu am dat la un moment dat despre un concept foarte interesant, numit YAGNI. Cercetează-l umpic.

Nu toți ajungem în situația de a lucra la o aplicație ce servește sute de mii de utilizatori simultan, ceea ce înseamnă că poate - doar poate - nu are rost să sacrificăm o grămadă de timp pe altarul performanței în ideea de „dar dacă…?”.

1 Like

Ceva pe tema asta…

Codul propriu îl poți mentena, codul unui framework nu îl poți mentena. Adică îl poți mentena, făcându-l al tău, preluând controlul (dar și responsabilitatea) făcând modificări directe în framework.

Dar asta defeats the purpose of using the framework in the first place.

În practică, upgradezi la o versiune mai nouă, dacă ea există, sau folosești un alt framework.

Dar stai.

Dacă acel framework ți-a acaparat tot codul, dacă îl apelezi pe fiecare a doua linie de cod din codul tău, atunci acel framework vechi te-a prins de oo și nu îți mai dă drumul. Ce faci, iei la mana fiecare linie de cod?

D-aia e bine să îți izolezi codul tău din start de orice framework sau librărie. Adică să ai toate apelurile la acel framework în locuri bine știute de inflexiune, unde poți intra cu buldozerul o dată și ai rezolvat problema.

Nu e un efort în plus să faci asta. În principiu un lucru important pe care îl ai de făcut e să nu urmezi orbește ce zic tutorialele din documentația acelui framework.

De exemplu, când documentația zice:

class YourClass extends FrameworkClass

Tu fă în schimb:

class YourClass { private FrameworkClass delegate; (e doar un exemplu, tehnica asta cu compoziția nu e aplicabilă mereu; ideea e: gândește-te în fiecare caz cum izolezi framework-ul a.î. să nu îți prindă de oo tot code base-ul)

Singurul caz în care se nu e valabil ce zic e când faci muncă pe firmituri, adică predai proiectul și te doare în pix de client, deoarece nu tu vei face mentenanța codului de-a lungul anilor care vor urma.

1 Like

Deci OP-ul acestui topic, ce-a vrut sa spuna, caci nu pricep.
A dat un link si un citat dintr-un articol.
Pe ce va contraziceti ca nu pricep

Din ce inteleg eu, se subliniaza cum arata purismul, mai precis se face diferentierea clara intre:

  1. nucleul aplicatiei, la nivel de concept si regulile de business (care la modul ideal e un “pachet” de sine statator, fara alte dependinte) si
  2. implementarea efectiva a functionalitatii, unde se pot folosi frameworkuri, librarii externe, etc (si chiar e recomandat acest lucru)

@Sapioit e fanul acestei abordari, cu totii suntem, si e bine sa invatam din ea cat mai multe. Punerea problemei in modul acesta e evident benefica, insa greu de pus in practica, cum bine observa @iamntz

Eu vin si starnesc putin intreband: dar oamenii aceia care au scris frameworkuri, nu au facut-o dintr-o necesitate de business? Adica nu au tot rescris ei anumite chestiuni de mai multe ori pana s-au decis sa standardizeze propriul lor mod de lucru si sa-l faca public?1

Cred ca totul trebuie privit in functie de durata de viata a proiectului, in sensul in care stim ca un simplu site de prezentare va fi refacut in cativa ani, pentru a tine pasul cu utilizatorii, deci ne putem cupla strans de un framework cu LTS declarat de 3 ani pentru a-l implementa pe frontend. In schimb, trebuie sa cantarim alte lucruri atunci cand implementam sau refunctionalizam un intreg flux de date. Acolo da, e bine ca sa avem cat mai mult cod independent de o anume librarie / un anume vendor.

Totusi, incercati sa va puneti in locul celui care are nevoie de acea functionalitate rescrisa / de la zero. Ce buget are? Cata energie este dispus sa investeasca sa inteleaga ce faceti voi acolo? Deciziile luate de voi il vor afecta financiar pe termen mediu si lung? Spuneti-i asta!

1: Exceptand evident pe nenea cu Laravel care a scris un framework doar ca sa invete el PHP. De aceea si arata asa codul, daca va puneti umpic pe sapat.

2 Likes

Mie chestia asta cu “mai bine faci in vanilla JS si nu folosesti nici un framework, caci freimorc-urile moare” mi se pare un bullshit total.
E precum in discutiile alea de acum 1000 de ani “ASM rules, C++ sucks”.

E normal sa fii precaut si sa nu adaugi orice library care o gasesti pe github la proiect, doar pentru ca e mai usor asa.

Dar de aici pana la a spune ca Angular, React, Backbone, Knockout e proaste caci ele moare si ca e mai bine fara ele, e o absurdidate si sunt convins ca cei care o scriu o fac, fie pentru ca e usor sa scrii pe internet toate tampeniile si sa te dai ciumeg, sau ca nu prea au experienta in domeniul respectiv.

In plus, altii se dau de ceasul mortii din alte motive.
De exemplu, Angular 1.x e bine mersi si va fi bine mersi pentru o perioada, poti folosi ES6/ES7, etc.
Ca nu e un framework perfect si ca are probleme, asta e altceva.
Dar mort nu e sigur, in parte pentru ca sunt deja multe proiecte scrise cu Angular 1.x.
Am ales ca exemplu Angula caci e popular, si nu din motive personale.

Inca ceva, articolul ala spune cam acelasi lucru:

We shouldn’t jump on new hype just because it’s new and people are talking about it in meetups. What we should do is learn, understand & experiment. I don’t want to be stuck again in a decade old framework nobody talks about or wants to work with.

We’re adding React.js today to our stack of Backbone.js. Backbone has served us well and we love it, but it’s time to move on. Moving forward after 3 years seems like a good timeframe for a change. It won’t be easy, and we’re not rewriting everything from scratch, but staying current with the times is worth it.

1 Like

Inca ceva: Chiar si companiile care au si folosesc un framework-ul scris in the house, nu-si imbunatatesc sau schimba framework-ul niciodata?
De exemplu, nu sunt oricum dependente de limbaj? E vreun limbaj care nu evolueaza?

1 Like

Ba da, il schimba, dar fiind in-house, nu trebuie sa verifice fiecare pull request venit de la orice anonim care a dat peste proiectul lor pe github si e de parere ca X lucru trebuie modificat.

tl;dr:

Not invented here (NIH) is the philosophical principle of not using third party solutions to a problem because of their external origins. False pride often drives an enterprise to use less-than-perfect invention in order to save face by ignoring, boycotting, or otherwise refusing to use or incorporate obviously superior solutions by others.

2 Likes