Vertailu Angularin ja Reactin ja niiden ydinkielien välillä

Tässä artikkelissa verrataan kahta vuoden 2019 suosituinta verkkoteknologiaa ja käsitellään myös niiden historiaa, keskeisiä eroja, suositeltuja ydinkieliä (TypeScript ja JavaScript) ja niin edelleen. Kaiken kaikkiaan nämä tekniikat ovat helpottaneet kehittäjien koodin uudelleenkäyttöä, korjaamista ja ylläpitoa jakamalla asiat moduuleiksi / komponenteiksi.

Tämän artikkelin tarkoituksena ei ole löytää parasta tekniikkaa, vaan verrata, korostaa ja selventää harva väärinkäsitys. Keskitymme myös tärkeään pienten yksityiskohtien sijaan, joilla ei ole väliä merkitystä pitkällä aikavälillä.

Sinun tulisi olla tietoinen siitä, että näiden kahden tekniikan vertailua ei voida täysin kattaa. Angularissa on täydellinen kehys (MVC), kun taas React on etukirjasto, jossa on paljon avoimen lähdekoodin paketteja integroitavaksi.

Jos haluat tulla paremmaksi web-kehittäjäksi, perustaa oma yrityksesi, opeta muita tai yksinkertaisesti kehitystaitojasi, tilaa tilaamasi uutiskirje, niin saat uusimmat verkkouutiset ja päivitykset.

Käsiteltävät kysymykset

  • Mitkä ovat tärkeimmät erot kulman ja reaktion välillä?
  • Mikä tekee TypeScriptistä niin erikoisen?
  • Kuinka suosittuja nämä tekniikat ovat?
  • Mikä on tämänhetkinen avoimen lähdekoodin tila?
  • Mitä tekniikkaa yritykset käyttävät eniten?
  • Vaikuttavatko staattisesti kirjoitetut kielet koodin laatuun ja kehitysaikaan?

Tulevat osiot lisätään kommenttien kysynnän perusteella.

Keskeiset vertailut

Tässä on nopea vertailu kulman (vasen) ja React (oikea) välillä.

Yksi asia, joka on todella hyvä Reactissa suorituskyvyn suhteen, on Virtual DOM, josta olet todennäköisesti kuullut pari kertaa. Jos ei, älä huoli, selitän sen!

Ongelma

Oletetaan, että haluat päivittää käyttäjän syntymäpäivän HTML-tunnisteiden sisällä.

Virtuaalinen DOM

Se päivittää vain vaadittavan osan näkemällä erot edellisen ja nykyisen HTML-version välillä. Se on samanlainen lähestymistapa GitHubin toimintaan havaitaessa tiedostomuutoksia.

Säännöllinen DOM

Se päivittää HTML-tunnisteiden koko puurakenteen, kunnes se saavuttaa syntymäajan.

Miksi sillä on väliä?

Sillä ei voi olla merkitystä yllä kuvatun ongelman kannalta. Jos kuitenkin käsittelemme 20–30 asynkronista tietopyyntöä samalla sivulla (ja jokaisella sivupyynnöllä korvataan koko HTML-lohko), se vaikuttaa sekä suorituskykyyn että käyttökokemukseen.

Tarvitsetko lisää kontekstia? Katso Dacen artikkeli!

Mutta ensin, takaisin alkuun ...

Historia

Meidän on tiedettävä vähän historiaa (konteksti), koska se antaa käsityksen siitä, miten asiat voivat muodostaa tulevaisuudessa.

En käsittele yksityiskohtia siitä, mitä Angularin ja AngularJS: n välillä tapahtui, ja olen varma, että käytettävissä on paljon resursseja, jotka kattavat sen. Lyhyesti sanottuna Google korvasi AngularJS: n Angularilla ja JavaScript TypeScriptillä.

Selvä, joten ES4 / ES5: n päivinä Java-oppimiskäyrä oli todella korkea. Jos tulit Java-, C #- tai C ++ -maailmasta, olio-ohjelmoinnin (OOP) maailmasta, JavaScriptin oppiminen ei yksinkertaisesti ollut niin intuitiivista. Toisin sanoen, se oli kipu perseeseen.

Se ei johdu siitä, että kieli oli kirjoitettu huonosti, vaan siksi, että sillä on erilainen tarkoitus. Se on rakennettu käsittelemään verkon asynkronista luonnetta, kuten käyttäjän vuorovaikutusta, tapahtumien sitomista, siirtymiä / animaatioita ja niin edelleen. Se on erilainen eläin, jolla on erilaiset vaistot.

Suosio

Kuten Google Trends paljastaa, Angular ja React ovat kaksi suosituinta verkkoteknologiaa vuonna 2019.

Angularilla on enemmän hakuhittejä kuin Reactilla, mutta se ei välttämättä tarkoita, että toinen on parempi kuin toinen. Mutta tämä osoittaa, mitä ihmiset pitävät mielenkiintoisina syystä riippumatta. On tärkeää olla tietoinen siitä, että ihmiset voivat sekoittaa avainsanoja, kuten AngularJS tai Angular, ja johtaa siten korkeampiin hakutuloksiin.

Yksi asia on varma - molemmat tekniikat kasvavat, ja tulevaisuus näyttää valoisalta. Tämä tarkoittaa, että sinun ei tarvitse huolehtia, jos yksi tekniikka epäonnistuu, ja jättää sinut taakseen.

On tärkeää, että emme unohda historiaa sen suhteen, mitä AngularJS: n ja Angularin välillä tapahtui, koska historia on osoitus siitä, mitä voi tapahtua tulevaisuudessa. Mutta jos sinulla on jonkin verran kokemusta AngularJS: stä, näet todennäköisesti, miksi päätökset tehtiin parempaan suuntaan. Ainoastaan ​​mainittakoon, että tällaisia ​​asioita voi tapahtua missä tahansa kehyksessä, mukaan lukien React.

Avoin lähdekoodi

Reactilla on yli 100 000 tähteä, 1200 avustajaa ja lähes 300 ratkaistavaa ongelmaa.

Reactilla on aika markkinoida, koska se julkaistiin 3 vuotta ennen Angularia. Ja se tarkoittaa, että se on kohdannut paljon tosielämän ongelmia, käynyt läpi kriittisiä testejä ja yleisesti on kehittynyt mukautuvaksi ja joustavaksi etukirjastoksi, jota monet rakastavat.

Angularin suhteen voimme ensi silmäyksellä selvästi nähdä, että Angularilla on 6 kertaa enemmän asioita kuin React (ei hyvä). Emme saa kuitenkaan unohtaa, että Angular on paljon suurempi kehys, ja sillä on myös vähemmän kehittäjiä, jotka käyttävät sitä (tällä hetkellä), koska se julkaistiin vuonna 2016.

Tilastot on otettu Angular and Reacts GitHub -sivulta.

Mitä yritykset käyttävät

React kehitettiin alun perin Facebookissa Facebookille komponenttien kehittämisen optimoimiseksi ja helpottamiseksi. Chris Cordlen kirjoittama artikkeli huomauttaa, että Reactilla on suurempi käyttö Facebookissa kuin Angularilla Googlessa.

Joten kuka käyttää mitä tekniikkaa?

# Reagoi

  • Facebook
  • AirBnb
  • Uber
  • Netflix
  • Instagram
  • Whatsapp
  • Dropbox

# Kulmikas

  • Syö24
  • CVS-kauppa
  • jalkapallo
  • Google Express
  • NBA
  • Delta
  • wix.com
Jos tiedät suuria (tunnettuja) yrityksiä, jotka käyttävät Angularia, jaa linkin kanssa.

TypeScript ja JavaScript (ES6 +)

Kuten mainitsin, voi olla harhaanjohtavaa verrata vain Angularia ja Reactia keskittymättä ydinkieleen, jota kukin on korostanut (asiakirjojensa mukaan).

Merkintä! Tämän osan tarkoituksena ei ole päättää, valitsemmeko kulma vai reagoi. Mutta selvitä muutama väärinkäsitys staattisesti - dynaamisesti kirjoitettujen kielten välillä, joka on jatkunut jo jonkin aikaa tutkimuksen tuella.

Käyttäjäkannan suhteen JavaScript on ylivoimainen. Mutta TypeScript kasvaa nopeasti, joten kuka tietää, mitä 10–15 vuotta tuo.

TypeScript-suosio viimeisten 5 vuoden aikana

JavaScriptin suosio viimeisten 5 vuoden aikana

JavaScript vs. TypeScript suosio viimeisten 5 vuoden aikana

Microsoft kirjoitti TypeScriptin alun perin helpottamaan JavaScriptiä (toisin sanoen ES5: n helpottamiseksi). Se julkaistiin lokakuussa 2012. Ja se on yksinkertaisesti transpileri, joka kääntää TypeScriptin JavaScript-koodiksi, mikä tarkoittaa myös, että voit kirjoittaa ES5-koodin TypeScript-tiedostoon. TypeScriptiä kutsutaan JavaScriptin supersetiksi.

Yleensä TypeScript tarjoaa sujuvan siirtymisen ohjelmoijille, joilla on olio-ohjelmoinnin (OOP) tausta. On tärkeää huomata, että TypeScript julkaistiin ES5: n aikana, ja tuona aikana ES5 ei ollut luokkaperusteinen OOP-kieli.

Lyhyesti sanottuna lähinnä voisit tulla luokkiin ja esineisiin tuolloin prototyyppiperinnön kautta. Ja kuten tiedämme, tämä oli vaikea siirtymä useimmille OOP-taustalla oleville kehittäjille. Joten ihanteellinen päätös oli tietysti valita jotain, joka tuntui mukavalta ja tutulta, mikä todennäköisesti oli TypeScript.

Viime vuosina JavaScript on kuitenkin kehittänyt ja toteuttanut paljon suuria muutoksia, kuten moduulit, luokat, hajautusoperaattorit, nuolitoiminnot, mallilitraalit ja niin edelleen. Kaiken kaikkiaan sen avulla kehittäjät voivat kirjoittaa deklaratiivisen koodin, samalla kun ne tukevat todellisen OOP-kielen ominaisuuksia (ts. Luokkaan perustuva rakenne).

Staattisesti ja dynaamisesti kirjoitetut kielet

Staattisesti kirjoitettu kieli tarkoittaa periaatteessa, että voit määrittää muuttujan tyypin (merkkijono, numero tai taulukko jne.). Voit kysyä, miksi tämä on tärkeää. Tässä on todellinen analogia, jonka olen määrittänyt (luovuus parhaimmillaan).

Oletetaan, että haluat tankata autosi polttoaineella. Yksi tärkeä asia on polttoaineet oikealla kaasulla - bensiinillä tai dieselillä. Ja jos et tiedä, sinun on ehkä ostettava uusi auto.

Tietysti vakavuus ei ole samanlainen kuin koodauksessa, mutta joissakin tapauksissa se voi olla. Ajattele sitä. Jos työskentelet suuren sovelluksen kanssa, haluaisit tietää välitetyn argumentin ja ominaisuuden tyypin, muuten saatat rikkoa koodin.

Selvä, joten jos olet edelleen hämmentynyt, mitä staattisesti kirjoitettu tarkoittaa, tarkista tämä:

Staattinen kirjoitettu ominaisuus

Staattinen kirjoitettu argumentti

Olen oppinut, että monet ihmiset uskovat, että staattisesti kirjoitettu kieli tarkoittaa luotettavaa koodia, ja sitä käytetään useimmiten voittavana argumenttina dynaamisesti kirjoitetuista kielistä. Ja rehellisesti sanottuna on melko vaikea kumota tätä väitettä, koska se perustuu pohjimmiltaan kehitysympäristöön, ohjelmoijien kokemukseen ja tietysti projektivaatimuksiin.

Onneksi tutkimus (tl; dr video) on ottanut tämän vakavasti ja kokeillut tätä myyttiä 49 koehenkilön kanssa.

Tutkimuksen havainnot ovat:

  • Staattisesti kirjoitettu kieli vaatii enemmän aikaa kirjoitusvirheiden korjaamisen takia
  • Dynaamisesti kirjoitettu kieli on luettavissa ja helpompi kirjoittaa (ilmoituskoodi)

Kuvio 5 osoittaa, että keskimäärin kehittäjät lyhentävät kehitysaikaansa kaksinkertaiseksi kirjoittaessaan dynaamisesti kirjoitettua kieltä.

Jos haluat syventää tätä aihetta, suosittelen lukemaan tämän Eric Elliottin artikkelin, jossa todetaan, että et ehkä tarvitse TypeScriptiä (tai staattisesti kirjoitettuja kieliä).

Mitä valita

Joten kysymys ei ole vain siitä, mitä Angular tai React tarjoaa, vaan myös siitä, mihin ydinkieleen sinun tulisi sijoittaa aikaa. Ja sillä ei ole väliä, kunhan valitset jotain, joka sopii tarpeisiisi ja monimutkaisuuteen.

Jos et ole tyyppiharrastaja, mikään ei estä kirjoittamasta ES6-koodia TypeScript-muodossa. Se on vain, että jos tarvitset sitä, se on siellä.

Mutta jos rakennat melko suuren käyttöliittymän, jossa on Angular, joka käsittelee monia HTTP-pyyntöjä, tyyppien käyttäminen auttaa todella kysymyksissä, kuten "minkä tyyppinen objekti tämä on, mitä kenttiä voin käyttää ja minkä tyyppinen tämä kenttä on jne." . Se toimii erinomaisesti yhteistyössä ja pienten asioiden selventämisessä.

Tässä on yksinkertainen luokka-objekti vertailu TS: n ja JS: n (ES6) välillä.

IMO

Staattisesti kirjoitettu tuntuu jäsennetyltä, turvalliselta, luettavalta ja helpolta yhteistyöltä muiden kanssa (estää ihmisiä välittämästä odottamattomia arvoja). Työskennellessäni dynaamisesti kirjoitettujen kanssa minulla on kuitenkin joustavuutta ja luovuutta keskittyä enemmän luomiseen kuin ajatella paljon tyypeistä, rajapinnoista, geneerisistä aineista ja niin edelleen.

Ja aikaisemmista rakentamistani verkkosovelluksista, minulla ei todellakaan ole ollut suuria ongelmia staattisen kirjoittamisen puuttumisesta. Se ei tarkoita, että en pidä siitä - minä vain en tarvitse sitä, mutta ehkä pidän tulevaisuudessa.

Tässä on päivitys - työskentelen tällä hetkellä parin Microsoft-kehittäjän kanssa sovelluksen rakentamiseksi Angular Framework -palvelua käyttäen. Syy, miksi olemme valinneet Angularin, johtuu siitä, että suurin osa paketeista on jo määritelty, ja kaiken dokumentaatio on yhdessä paikassa. Se korostaa myös TypeScriptiä, joka on täydellinen valinta, koska suurimmalla osalla dev-ohjelmista on jo paljon kokemusta olio-ohjelmoinnista.

Toisaalta olen nähnyt vastaavia sovelluksia, joiden kanssa työskentelemme, rakennettu Reactin kanssa. Joten molemmat ovat tehokkaita työkaluja, ja ne riippuvat enimmäkseen arkkitehtuurin määrittämisestä.

Takeaway-muistiinpanot

  • TypeScript on yksinkertaisesti transpileri, sitä voidaan käyttää Reactin tai minkä tahansa muun JS-kehyksen kanssa
  • React hoitaa muistinhallinnan tehokkaasti (virtuaalinen DOM)
  • React käyttää JavaScriptiä (ES6), joka on tunnustettu verkkokieli vuodesta 1995
  • Angular käyttää TypeScriptia, julkaistu vuonna 2012
  • Staattisesti kirjoitettu kieli on hieno, mutta sen ei tarvitse olla
  • Dynaamisesti kirjoitetut kielet vaativat vähemmän aikaa kirjoittamiseen ja enemmän joustavuutta luovuuden käyttöön
  • Staattisesti kirjoitetun kielen oppiminen voi olla haaste, varsinkin jos olet työskennellyt vain dynaamisesti kirjoitettujen kielten kanssa
  • ES6 on ottanut käyttöön monia hienoja ominaisuuksia, kuten moduulit, luokat, levitysoperaattori, nuolitoiminnot, mallilitraalit, joiden avulla voit kirjoittaa vähemmän, puhtaampaa ja jäsennellympää koodia (syntaktinen sokeri)
  • TS on yksinkertaisesti ES6 +, tyypit ja paljon muuta

Johtopäätös

Valitsemasi kehys / komponenttikirjasto voi vaikuttaa siihen, kuinka paljon aikaa vietät ohjelmointiin ja budjettiin. Jos sinulla on tiimi, jossa on C #, Java tai C ++ -kehittäjiä, suosittelen todennäköisesti Angularia, koska TypeScript jakaa monia yhtäläisyyksiä näiden kielten kanssa.

Paras suositus, jonka voin tarjota, on perustaa perussovellus sekä Angular- että React-sovelluksiin ja arvioida sitten kieli ja työnkulku ennen päätöksen tekemistä.

Kuten aiemmin mainittiin, molemmilla tekniikoilla on omat etunsa ja yhtäläisyytensä, ja se todellakin supistuu siihen, minkä tyyppisiä vaatimuksia sovellus tarjoaa, kehittäjien monimutkaisuus ja kokemustaso.

Tässä on muutama artikkeli, jonka olen kirjoittanut verkkoekosysteemistä, sekä henkilökohtaiset ohjelmointivinkit.

  • Kaoottinen mieli johtaa kaoottiseen koodiin
  • Kehittäjät, jotka haluavat jatkuvasti oppia uusia asioita
  • Käytännön opas ES6-moduuleihin
  • Opi nämä Web-käsitteet
  • Paranna taitojasi näillä tärkeillä JavaScript-menetelmillä
  • Ohjelmoi nopeammin luomalla mukautettuja bash-komentoja

Löydät minut Mediumista, josta julkaisen viikoittain. Tai voit seurata minua Twitterissä, johon lähetän asiaankuuluvia verkkokehitysvinkkejä ja temppuja yhdessä henkilökohtaisten tarinoiden kanssa.

PS Jos pidit tästä artikkelista ja haluat lisää, taputa ❤ ja jaa ystävien kanssa, jotka saattavat tarvita sitä, se on hyvä karma.