![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Non se creou marcos de JavaScript durante a redacción deste artigo.
O seguinte está inspirado no artigo "É o futuro" de Circle CI. Podes ler o orixinal aquí . Esta peza é só unha opinión e, como calquera framework de JavaScript, non se debe tomar demasiado en serio.
Ei, teño este novo proxecto web, pero para ser sincero, non codifiquei moito web desde hai uns anos e escoitei que o panorama cambiou un pouco. Vostede é o desenvolvedor web máis actualizado por aquí, non?
-O termo real é enxeñeiro de Front End, pero si, son o tipo adecuado. Fago web en 2016. Visualizacións, reprodutores de música, drons voadores que xogan ao fútbol, o que sexa. Acabo de volver de JsConf e ReactConf, polo que coñezo as tecnoloxías máis recentes para crear aplicacións web.
Genial. Necesito crear unha páxina que mostre a actividade máis recente dos usuarios, polo que só teño que obter os datos do punto final REST e mostralos nalgún tipo de táboa filtrable e actualizalos se algo cambia no servidor. Estaba pensando que quizais usar jQuery para buscar e mostrar os datos?
-Oh meu deus non, xa ninguén usa jQuery. Deberías tentar aprender React, é 2016.
Ah, vale. Que é React?
-É unha biblioteca moi xenial feita por algúns rapaces de Facebook, realmente aporta control e rendemento á túa aplicación, ao permitirche xestionar calquera cambio de vista con moita facilidade.
Iso soa ben. Podo usar React para mostrar datos do servidor?
-Si, pero primeiro debes engadir React e React DOM como biblioteca na túa páxina web.
Espera, por que dúas bibliotecas?
-Entón, unha é a biblioteca real e a segunda é para manipular o DOM, que agora podes describir en JSX.
JSX? Que é JSX?
-JSX é só unha extensión de sintaxe de JavaScript que se parece bastante a XML. É outra forma de describir o DOM, pensa nel como un HTML mellor.
Que ten de malo HTML?
-É 2016. Xa ninguén codifica HTML directamente.
Certo. De todos os xeitos, se engado estas dúas bibliotecas, podo usar React?
-Non do todo. Debes engadir Babel e despois poderás usar React.
Outra biblioteca? Que é Babel?
-Oh, Babel é un transpiler que che permite apuntar a versións específicas de JavaScript, mentres codificas en calquera versión de JavaScript. Non tes que incluír a Babel para usar ReactJS, pero a non ser que o fagas, tes que usar ES5, e sexamos reais, é 2016, deberías estar codificando en ES2016+ como fan o resto dos nenos xeniais.
ES5? ES2016+? Estou perdendo por aquí. Que é ES5 e ES2016+?
-ES5 é a sigla de ECMAScript 5. É a edición que máis xente ten como destino xa que foi implementada pola maioría dos navegadores hoxe en día.
ECMAScript?
-Si, xa sabes, o estándar de scripts JavaScript baseouse en 1999 despois do seu lanzamento inicial en 1995, entón cando JavaScript se chamaba Livescript e só funcionaba no Netscape Navigator. Daquela era moi desordenado, pero afortunadamente agora as cousas están moi claras e temos, como, 7 edicións desta implementación.
7 edicións. De verdade. E ES5 e ES2016+ son?
-A quinta e a sétima edición respectivamente.
Espera, que pasou co sexto?
-Queres dicir ES6? Si, quero dicir, cada edición é un superconxunto da anterior, polo que se estás a usar ES2016+, estás usando todas as funcións das versións anteriores.
Certo. E por que usar ES2016+ sobre ES6?
-Ben, PODERÍAS usar ES6, pero para usar funcións interesantes como async e await, necesitas usar ES2016+. En caso contrario, estás atascado con xeradores ES6 con corrutinas para bloquear chamadas asíncronas para un fluxo de control adecuado.
Non teño nin idea do que acabas de dicir, e todos estes nomes son confusos. Mira, só estou cargando unha morea de datos dun servidor, adoitaba incluír jQuery desde un CDN e obter os datos con chamadas AJAX, por que non podo facelo?
-É o 2016 home, xa ninguén usa jQuery, acaba nunha chea de código espagueti. Todo o mundo sábeo.
Certo. Entón, a miña alternativa é cargar tres bibliotecas para obter datos e mostrar unha táboa HTML.
-Ben, inclúas esas tres bibliotecas pero combínaas cun xestor de módulos para cargar só un ficheiro.
Xa vexo. E que é un xestor de módulos?
-A definición depende do entorno, pero na web adoitamos dicir calquera cousa que admita módulos AMD ou CommonJS.
Riiight. E AMD e CommonJS son...?
-Definicións. Hai formas de describir como deben interactuar varias bibliotecas e clases de JavaScript. Sabes, exporta e require? Podes escribir varios ficheiros JavaScript que definen a API de AMD ou CommonJS e podes usar algo como Browserify para agrupalos.
Vale, iso ten sentido... Creo. Que é Browserify?
-É unha ferramenta que permite agrupar as dependencias descritas de CommonJS en ficheiros que se poden executar no navegador. Creouse porque a maioría da xente publica esas dependencias no rexistro npm.
rexistro npm?
-É un repositorio público moi grande onde a xente intelixente pon código e dependencias como módulos.
Como un CDN?
-Realmente non. É máis parecido a unha base de datos centralizada onde calquera pode publicar e descargar bibliotecas, polo que pode usalas localmente para o desenvolvemento e despois cargalas nun CDN se o desexa.
Oh, como Bower!
-Si, pero agora estamos en 2016, xa ninguén usa Bower.
Ah, xa vexo... entón teño que descargar as bibliotecas de npm?
-Si. Entón, por exemplo, se queres usar React, descarga o módulo React e impórtao no teu código. Podes facelo para case todas as bibliotecas JavaScript populares.
Oh, como Angular!
-Angular é así de 2015. Pero si. Angular estaría alí, xunto a VueJS ou RxJS e outras bibliotecas interesantes de 2016. Queres aprender sobre eles?
Quedemos con React, xa estou aprendendo demasiadas cousas. Entón, se necesito usar React, cólleo deste npm e despois uso isto de Browserify?
-Si.
Parece demasiado complicado coller unha morea de dependencias e vinculalas.
-É por iso que usas un xestor de tarefas como Grunt ou Gulp ou Broccoli para automatizar a execución de Browserify. Diablos, incluso podes usar Mimosa.
Gruñón? Gulp? Brócolis? Mimosa? Que carallo estamos a falar agora?
-Xestores de tarefas. Pero xa non son xeniais. Usámolos en 2015, despois usamos Makefiles, pero agora envolvemos todo con Webpack.
Makefiles? Pensei que se usaba principalmente en proxectos C ou C++.
-Si, pero polo visto na web encántanos facer as cousas complicadas e volver despois ao básico. Facemos iso todos os anos máis ou menos, só hai que esperar, imos facer a montaxe na web nun ou dous anos.
Suspiro. Mencionaches algo chamado Webpack?
-É outro xestor de módulos para o navegador, mentres que tamén é unha especie de corredor de tarefas. É como unha versión mellor de Browserify.
Oh, ok. Por que é mellor?
-Pois quizais non mellor, só é máis opinado sobre como se deben amarrar as súas dependencias. Webpack permítelle usar diferentes xestores de módulos, e non só os CommonJS, polo que, por exemplo, os módulos nativos compatibles con ES6.
Estou moi confuso con todo isto de CommonJS/ES6.
-Todos o son, pero xa non debería importarlle SystemJS.
Xesucristo, outro substantivo-js. Ok, e que é este SystemJS?
-Ben, a diferenza de Browserify e Webpack 1.x, SystemJS é un cargador de módulos dinámico que che permite vincular varios módulos en varios ficheiros en lugar de agrupalos nun ficheiro grande.
Agarda, pero pensei que queriamos construír as nosas bibliotecas nun ficheiro grande e cargalo!
-Si, pero porque agora chega HTTP/2 varias solicitudes HTTP son realmente mellores.
Agarda, entón non podemos engadir as tres bibliotecas orixinais para React?
-Realmente non. Quero dicir, podes engadilos como scripts externos desde un CDN, pero aínda así terás que incluír Babel.
Suspiro. E iso é malo non?
-Si, estarías incluíndo todo o babel-core, e non sería eficiente para a produción. Na produción, debes realizar unha serie de tarefas previas para preparar o teu proxecto que fan que o ritual para convocar a Satanás pareza unha receita de ovos cocidos. Necesitas minificar os recursos, feos, css en liña por riba do fold, aprazar scripts, así como-
Eu teño, eu teño. Entón, se non incluirías as bibliotecas directamente nun CDN, como o farías?
-Transpilaríao desde Typescript usando un combo Webpack + SystemJS + Babel.
¿Mecanografiado? Pensei que estabamos codificando en JavaScript!
-Typescript É JavaScript, ou mellor dito, un superconxunto de JavaScript, máis concretamente JavaScript na versión ES6. Sabes, esa sexta versión da que falamos antes?
Pensei que ES2016+ xa era un superconjunto de ES6! POR QUE necesitamos agora esta cousa chamada Typescript?
-Oh, porque permítenos usar JavaScript como linguaxe de escritura e reducir os erros de execución. É 2016, deberías engadir algúns tipos ao teu código JavaScript.
E Typescript obviamente fai iso.
-Flow tamén, aínda que só verifica a escritura mentres Typescript é un superconxunto de JavaScript que debe compilarse.
Suspiro... e Flow é?
-É un verificador de tipos estáticos feito por uns rapaces de Facebook. Codificárono en OCaml, porque a programación funcional é incrible.
OCaml? ¿Programación funcional?
-É o que usan hoxe os mozos guapos home, sabes, 2016? ¿Programación funcional? Funcións de alta orde? Curry? Funcións puras?
Non teño nin idea do que acabas de dicir.
-Ninguén fai ao principio. Mira, só tes que saber que a programación funcional é mellor que OOP e iso é o que deberíamos usar en 2016.
Espera, aprendín OOP na universidade, pensei que era bo?
-Tamén estaba Java antes de ser comprado por Oracle. Quero dicir, OOP era bo nos tempos, e aínda ten os seus usos hoxe en día, pero agora todo o mundo está a entender que modificar estados é equivalente a dar patadas aos bebés, polo que agora todos están pasando a obxectos inmutables e programación funcional. Os rapaces de Haskell levaban anos chamándoo, -e non me empecedes cos de Elm- pero por sorte na web agora temos bibliotecas como Ramda que nos permiten usar programación funcional en JavaScript simple.
Estás soltando nomes por iso? Que diaños é Ramnda?
-Non. Ramda. Como Lambda. Sabes, esa biblioteca de David Chambers?
David quen?
-David Chambers. Cara xenial. Xoga un xogo de golpe de estado. Un dos colaboradores de Ramda. Tamén deberías consultar a Erik Meijer se te queres aprender en serio a programación funcional.
E Erik Meijer é...?
-Programador funcional tamén. Mozo incrible. Ten unha morea de presentacións nas que tira ao lixo Agile mentres usa esta camisa de cores estrañas. Tamén deberías consultar algunhas das cousas de Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani-
Ok. Vou parar alí. Todo iso é bo e bo, pero creo que todo iso é tan complicado e innecesario para buscar datos e mostralos. Estou bastante seguro de que non necesito coñecer a estas persoas nin aprender todas esas cousas para crear unha táboa con datos dinámicos. Volvemos a React. Como podo obter os datos do servidor con React?
-Ben, en realidade non buscas os datos con React, só mostras os datos con React.
Ai, carallo. Entón, que usas para obter os datos?
-Utiliza Fetch para obter os datos do servidor.
Sintoo? Usas Fetch para obter os datos? Quen estea nomeando esas cousas necesita un tesauro.
-Seino non? Obter é o nome da implementación nativa para realizar XMLHttpRequests contra un servidor.
Ah, entón AJAX.
-AJAX é só o uso de XMLHttpRequests. Pero seguro. Fetch permítelle facer AJAX baseado en promesas, que entón podes resolver para evitar o inferno de devolución de chamadas.
Inferno de devolución de chamada?
-Si. Cada vez que realizas unha solicitude asíncrona contra o servidor, cómpre esperar a súa resposta, o que fai que engadas unha función dentro dunha función, que se chama a pirámide de devolución de chamada do inferno.
Oh, ok. E esta promesa resolve-lo?
-De feito. Ao manipular as túas devolucións de chamada a través de promesas, podes escribir códigos máis fáciles de entender, simulalas e probalas, así como realizar solicitudes simultáneas á vez e esperar ata que se carguen todas.
E iso pódese facer con Fetch?
-Si, pero só se o teu usuario utiliza un navegador evergreen, se non, debes incluír un Polyfill Fetch ou usar Request, Bluebird ou Axios.
Cantas bibliotecas teño que coñecer por Deus? Cantos son deles?
-É JavaScript. Ten que haber miles de bibliotecas que fan todas o mesmo. Coñecemos bibliotecas, de feito, temos as mellores bibliotecas. As nosas bibliotecas son enormes e ás veces incluímos nelas imaxes de Guy Fieri.
Acabas de dicir Guy Fieri? Rematemos con isto. Que fan estas bibliotecas Bluebird, Request e Axios?
-Son bibliotecas para realizar XMLHttpRequests que devolven promesas.
O método AJAX de jQuery non empezou a devolver promesas tamén?
-Xa non usamos a palabra “J” en 2016. Simplemente use Fetch e compléteo cando non estea nun navegador ou use Bluebird, Request ou Axios. A continuación, xestiona a promesa con await dentro dunha función asíncrona e boom, tes un fluxo de control adecuado.
É a terceira vez que mencionas esperar pero non teño nin idea de que é.
-Await permítelle bloquear unha chamada asíncrona, o que lle permite ter un mellor control sobre cando se están a recuperar os datos e aumentar a lexibilidade do código en xeral. É incrible, só tes que asegurarte de engadir o preset stage-3 en Babel ou usar as funcións syntax-async-functions e transform-async-to-generator plugin.
Isto é unha tolemia.
-Non, tolo é o feito de que cómpre precompilar o código Typescript e despois transpilalo con Babel para usar await.
Que? Non está incluído en Typescript?
-Faino na seguinte versión, pero a partir da versión 1.7 só se dirixe a ES6, polo que se queres usar await no navegador, primeiro debes compilar o teu código Typescript dirixido a ES6 e despois a Babel esa merda ata a ES5.
A estas alturas non sei que dicir.
-Mira, é doado. Codifica todo en Typescript. Todos os módulos que usan Fetch compílanos para apuntar a ES6, transpílanos con Babel nun preset de fase 3 e cárganos con SystemJS. Se non tes Fetch, complétao ou usa Bluebird, Request ou Axios e xestiona todas as túas promesas coa espera.
Temos definicións moi diferentes de fácil. Entón, con ese ritual por fin conseguín os datos e agora podo mostralos con React, non?
-¿A súa aplicación vai xestionar algún cambio de estado?
Err, non o creo. Só teño que mostrar os datos.
-Oh, grazas a Deus. Se non, tería que explicarche Flux e implementacións como Flummox, Alt, Fluxible. Aínda que para ser honesto deberías usar Redux.
Vou simplemente sobrevoar eses nomes. De novo, só teño que mostrar datos.
-Oh, se só estás a mostrar os datos, non necesitabas React para comezar. Estaríache ben cun motor de modelos.
Estás bromeando? Cres que isto é divertido? É así como tratas aos teus seres queridos?
-Só estaba explicando o que podías usar.
Pare. Só para.
-Quero dicir, aínda que só use o motor de modelos, aínda usaría un combo Typescript + SystemJS + Babel se fose ti.
Necesito mostrar datos nunha páxina, non realizar a fatalidade MK orixinal de Sub Zero. Simplemente dime que motor de plantillas usar e levarei a partir de aí.
-Hai moito, cal coñeces?
Uf, non me lembro do nome. Foi hai moito tempo.
-jModelos? jQote? PURO?
Err, non soa un timbre. Outra?
-¿Transparencia? JSRender? MarkupJS? KnockoutJS? Aquela tiña encadernación bidireccional.
Outra?
-PlatosJS? jQuery-tmpl? ¿Manillares? Algunhas persoas aínda o usan.
Quizais. Hai semellantes a este último?
-Bigote, subliñado? Creo que agora incluso Lodash ten un para ser honesto, pero son un tipo de 2014.
Err.. quizais era máis novo.
-Xade? DustJS?
Non.
-DotJS? EJS?
Non.
-¿Monxas? ECT?
Non.
-Mah, a ninguén lle gusta a sintaxe de Coffeescript de todos os xeitos. Xade?
Non, xa dixeches Jade.
-Quería dicir Pug. Quería dicir Jade. Quero dicir, Xade agora é Pug.
Suspiro. Non. Non me lembro. Cal usarías?
-Probablemente só cadeas de modelos nativos de ES6.
Déixame adiviñar. E iso require ES6.
-Correcto.
O cal, dependendo do navegador que estea usando necesita Babel.
-Correcto.
O cal, se quero incluír sen engadir toda a biblioteca principal, teño que cargalo como módulo desde npm.
-Correcto.
O que require Browserify, ou Wepback, ou moi probablemente esa outra cousa chamada SystemJS.
-Correcto.
Que, a non ser que sexa Webpack, idealmente debería ser xestionado por un encargado de tarefas.
-Correcto.
Pero, dado que debería estar usando programación funcional e linguaxes de escritura, primeiro teño que compilar previamente Typescript ou engadir este elemento Flow.
-Correcto.
E despois mándao a Babel se quero usar await.
-Correcto.
Entón podo usar Fetch, promesas e control de fluxo e toda esa maxia.
-Non esquezas facer Polyfill Fetch se non é compatible, Safari aínda non pode manexalo.
Xa sabes que. Creo que rematamos aquí. De feito, creo que rematei. Acabei coa web, rematei con JavaScript.
-Está ben, dentro duns anos todos imos estar codificando en Elm ou WebAssembly.
Só vou volver ao backend. Non podo manexar estes moitos cambios e versións e edicións e compiladores e transpiladores. A comunidade JavaScript é unha tola se pensa que alguén pode seguir isto.
-Escoito. Deberías probar a comunidade Python entón.
Por que?
-Algunha vez escoitou falar de Python 3?
Actualización: Grazas por sinalar erros tipográficos e erros, actualizarei o artigo tal e como se indica. Discusión en HackerNews e Reddit .