Recentemente, a equipe Qwintry iniciou uma migração ativa para o Vue.js em todos os nossos projetos antigos e novos:- em um sistema legado baseado em Drupal (qwintry.com)
- em nosso novo segmento qwintry.com completamente reescrito (back-end em Yii2 / Node.js)
- em nossos sistemas B2B (com tecnologia Yii2) (logistics.qwintry.com)
- em todos os nossos pequenos projetos internos e públicos (principalmente usando PHP e Node.js no back-end)
Por que nossos programadores optaram pelo Vue.js, diz o chefe de desenvolvimento da Qwintry LLC . Anton Sidashin ➔Resumidamente sobre nós: o projeto Qwintry é usado por meio milhão de clientes em todo o mundo, temos dois armazéns (nos EUA e na Alemanha) usando nosso próprio software em nuvem e somos um dos maiores encaminhadores de correio dos EUA em termos de tráfego de visitantes e partidas. Ajudamos as pessoas a comprar mercadorias nas lojas on-line dos EUA e gerenciar suas encomendas em nossa conta pessoal, assim como podemos economizar significativamente em remessas internacionais. Utilizamos nossa própria plataforma de TI e cadeias de suprimentos para fornecer entrega internacional de qualidade a um bom preço.
Nosso pacote na porta do cliente - a partir de avaliações de clientesO Qwintry possui uma base de códigos bastante grande, composta principalmente por PHP e JS (+ Swift e Java para aplicativos móveis).Decidimos usar o Vue.js após criarmos um aplicativo de teste com funcionalidade idêntica - nossa calculadora - no React, no Vue.js e no Angular2. React.js
A popularidade do React disparou nos últimos dois anos e agora, talvez, seja a opção padrão para um desenvolvedor de JS que deseja escrever algo mais complicado no front-end do que um parágrafo de código de três linhas.Vimos vários SPA e widgets dinâmicos no React, testamos o React Native (para iOS) e o Redux. Eu acho que o React foi um grande passo para o mundo JS em termos de conscientização do estado , e mostrou a muitas pessoas o que é uma programação funcional real de uma maneira boa e pragmática. Eu também acho que o React Native é ótimo - literalmente muda todo o cenário do desenvolvimento móvel.Reagir desvantagens para mim:
Muitas vezes, limpeza, imunidade e ideologia dominam a abordagem pragmática.
Não me interpretem mal. Aprecio a pureza e simplicidade da abordagem render () - sem dúvida, essa é uma ótima idéia que funciona em desenvolvimento real. Eu estou falando de outras coisasEu acho que esse nível de rigor e limpeza pode ser útil quando você tem 1.000 desenvolvedores em sua empresa - ao mesmo tempo em que decide desenvolver sua própria sintaxe para traduzir todo o seu código PHP em tipos estáticos . Ou quando você é um desenvolvedor Haskell que decidiu compreender o JS. Mas a maioria das empresas tem muito menos desenvolvedores, orçamentos e objetivos menores que diferem dos objetivos do Facebook. Vou me aprofundar nisso mais detalhadamente.JSX é uma merda
Espere um segundo! Eu sei! Isso é "apenas Javascript puro com sintaxe especial". Nossos profissionais que desenham um desenho em um esboço e photoshop e depois o convertem para HTML, que têm prazos rígidos e que agora criam esse formulário envolvendo-o em várias divs - agora - o tambor está limpo e "simples" ES6 A aplicação de algum design aos componentes do React não é uma fonte, porque o JSX não tem legibilidade. A incapacidade de colocar o bom e velho FI em algum bloco de código HTML é ruim, e não confie nos fãs do React que dizem que “se () é o século passado, e agora todos os programadores normais usam operadores ternários”. Deixe-me assegurar-lhe: o JSX ainda é uma mistura de HTML e JS no momento em que você o lê e edita, mesmo que mais tarde seja compilado em JS puro.<ul>
{items.map(item =>
<li key={item.id}>{item.name}</li>
)}
</ul>
Muitos desenvolvedores pensam (e eu concordo com eles há algum tempo) que essas restrições de sintaxe os tornarão mais fortes e os ajudarão a escrever código mais modular, porque as limitações de JSX (prontas para uso) forçam você a colocar trechos de código em pequenas funções auxiliares e usá-los dentro As funções render (), como este e muitos outros caras sugeriram:stackoverflow.com/a/38231866/1132016JSX também obriga a dividir componentes em 15 linhas HTML em 3 componentes, 5 linhas HTML em cada. Não pense que essa abordagem o torna um desenvolvedor melhor.Aqui está a coisa:Quando você escreve um componente relativamente complexo - que você provavelmente não publicará amanhã em um representante público no GitHub para demonstrá-lo no HackerNews - essa abordagem de dividir componentes em componentes super burros devido a limitações de JSX sempre o tira do fluxo, em que você resolve um problema de negócios real. Não, não estou dizendo que a ideia de componentes fracionários seja ruim ou não esteja funcionando. Você deve estar ciente de que precisa dividir a funcionalidade em seus componentes para manter seu código em um estado controlado. Mas você deve fazê-lo apenas se você pensar que esta entidade lógica especial em seu código é melhor ser um componente separado com seus próprios adereços - e nãopara cada duas ou três condições que foram escritas usando o operador ternário! Cada vez que você cria um novo componente aqui e ali, custa um esforço muito específico e interrompe seu fluxo., porque você precisa mudar do pensamento do arquiteto (quando você já se lembra do estado atual do modelo de componente e só precisa adicionar HTML aqui e ali para que a funcionalidade funcione) para o pensamento do gerente: você precisa criar um arquivo separado para o componente, pense nos adereços desse novo componente como eles são mapeados no estado, como você encaminhará retornos de chamada etc. Como resultado, a velocidade de escrita do código é reduzida, porque você precisa gastar esforços na modularidade prematura dos componentes onde provavelmente não precisaria, se a sintaxe JSX fosse mais flexível. Na minha opinião, a modularidade prematura é muito semelhante à otimização prematura. Para mim e nossa equipe, a legibilidade do código é importante, mas ainda é muito importante gostar de escrever código. Não é legalquando uma forma simples de calculadora requer a criação de 6 componentes, cada um com seus próprios acessórios.Frequentemente, essa hipermodularidade também é ruim do ponto de vista da manutenção, modificação ou aplicação de um novo design, porque, para atualizar o html no widget, você precisa pular vários arquivos / funções e verificar cada pequeno pedaço de HTML separadamente.Novamente, não proponho escrever monólitos. Sugiro usar componentes em vez de microcomponentes para programação diária. É sobre equilíbrio e bom senso.Trabalhar com formulários e Redux fará com que você imprima o dia inteiro
Reagir - trata-se de limpeza e fluxo unidirecional, lembra? É por isso que o LinkedStateMixin se tornou uma persona non grata.e agora você deve escrever 10 funções para obter entrada de 10 campos de formulário. Não, é claro que você pode escrever uma função que verificará o e.target, mas no final haverá uma árvore de condições com a normalização dos dados que chegam do formulário que você deseja chorar; portanto ninguém faz isso. 80% dessas funções conterão uma linha com this.setState () ou uma chamada para a ação Redux. (Então você provavelmente terá que criar mais 10 constantes - uma para cada ação). Eu acho que essa abordagem seria aceitável se você pudesse gerar todo esse código apenas pensando nisso ... Mas eu não conheço nenhum editor de IDE que possa simplificar bastante a escrita de um clichê desse tipo. Por que você deveria imprimir tanto? Porque os grandes decidiram que a ligação bidirecional é perigosa em aplicativos corporativos de grande porte.Posso confirmar que a ligação bidirecional às vezes não é tão simples nem tão legível, mas a maioria desses medos está relacionada ao sofrimento geral das pessoas da primeira versão do Angular, onde a ligação bidirecional pode não ser a melhor. E, no entanto ... esse provavelmente não foi o maior erro de cálculo, mesmo em Angular. Olhe para o meu editor rápido, que recentemente alimentei o Vue.js em nossa plataforma Drupal (peço desculpas antecipadamente pelo design, este é o back-end da interface do usuário para nossos operadores e os designers estão ocupados criando interfaces para nossos clientes, portanto, essa parte da funcionalidade está aguardando a sua horas para ficar bonita):provavelmente não foi o maior erro de cálculo, mesmo em Angular. Olhe para o meu editor rápido, que recentemente alimentei o Vue.js para a nossa plataforma Drupal (peço desculpas antecipadamente pelo design, este é o back-end da interface do usuário para nossos operadores e os designers estão ocupados criando interfaces para nossos clientes, portanto, essa parte da funcionalidade está aguardando a sua horas para ficar bonita):provavelmente não foi o maior erro de cálculo, mesmo em Angular. Olhe para o meu editor rápido, que recentemente alimentei o Vue.js para a nossa plataforma Drupal (peço desculpas antecipadamente pelo design, este é o back-end da interface do usuário para nossos operadores e os designers estão ocupados criando interfaces para nossos clientes, portanto, essa parte da funcionalidade está aguardando a sua horas para ficar bonita):
Não consigo mostrar o código por razões óbvias, mas escrevê-lo no Vue foi muito bom e o código foi muito legível. E tenho certeza de que, se escrevesse uma função separada para cada campo do formulário, como em React, certamente não sairia da felicidade.Redux também é detalhado e requer muita escrita . E na Internet, é fácil encontrar declarações de desenvolvedores que acusam o Mobx de transformar o React em Angular apenas porque o Mobx usa ligação de dados bidirecional (consulte a seção 1 sobre "limpeza"). Parece que muitas pessoas inteligentes valorizam mais a "limpeza" de seu código do que a tarefa comercial rápida e bem resolvida (que, em princípio, é normal se você não tiver prazos).Ao mesmo tempo, considero o próprio conceito Flux / Redux muito legal. O Redux é simples e fornece um nível incrível de controle sobre o estado do aplicativo e separa o estado das partes puramente da interface - isso facilita imediatamente a gravação de testes. Mas, infelizmente, tudo isso é dado por uma quantidade muito grande de rabiscos. Sim, a depuração da viagem no tempo como um efeito colateral é impressionante. Mas, pessoalmente, estou pronto para sacrificá-lo em prol da escrita de código em alta velocidade e pensar se você precisa de viagens no tempo, se precisar criar uma constante para cada campo no formulário.Excesso excessivo de ferramentas
O React funciona com o escopo original em Babel. Você não criará um aplicativo React real sem um monte decente de pacotes npm, começando com o compilador ES5. Um aplicativo simples baseado na construção inicial oficial da carga recebe cerca de 75 MB de código JS em node_modules. Isso não é algo crítico e se relaciona mais ao mundo JS como um todo do que ao React, mas ainda acrescenta frustração e aborrecimento.Veredicto My React - permite que você escreva códigos ótimos e legíveis, mas escrever muito não é divertido. Bem, problemas para designers de layout que não possuem e não desejam possuir o ES6 dentro do HTML - não desaparecem.Angular 1: Muita liberdade também é ruim
O Angular 1 é uma boa estrutura para sua época, localizada no canto oposto (de React) de um mapa JS imaginário de limpeza e legibilidade do código. O Angular permite que você inicie rapidamente, permite que você goste de escrever as primeiras 1k linhas de código e, em seguida, praticamente faz você escrever código que não funciona muito bem. É provável que você se perca nas diretivas, escopos e fluxos de dados bidirecionais que penetram em todas as camadas do seu aplicativo, que serão o acorde final da música cisne do seu código, que os desenvolvedores contratados recentemente nem vão querer tocar, porque algo irá quebrar. Por que isso está acontecendo? O Angular.js foi criado em 2009, quando o mundo do desenvolvimento front-end parecia bastante simples e ninguém sequer pensava em um bom controle sobre o estado do aplicativo. Você não deve culpar os autores - eles apenas criaram um concorrente para o Backbone com alguns chips novos e queriam imprimir menos (e eles fizeram tudo isso, outra pergunta a que custo).Angular2
Basta criar um aplicativo olá mundo e ver o número de arquivos que acabam no nabo. Vou ter que usar o Typecript (e não tenho 100% de certeza do que quero fazer todos os dias - não, pessoal, a digitação estática em JS não é uma panacéia, mas mais uma vez tenho que imprimir, boas idéias de Eric Eliott sobre este tópico) e compiladores para começar. Isso foi o suficiente para adiarmos o Angular2 para tempos melhores. Sou preguiçoso e, para mim, é muito clichê antes de começar a escrever código real. Na minha opinião, os autores do Angular 2 estão tentando criar um sistema ideal para uma empresa que derrotará o React, em vez de tentar criar uma estrutura que resolva problemas de negócios para um usuário comum e médio. Talvez eu esteja errado, e minha opinião possa mudar - não tenho muita experiência no Angular2, acabamos de criar um aplicativo de calculadora de teste. Uma página de comparação maravilhosa no Vue.js chama o Angular2 de um bom sistema, com muitas idéias em comum com o Vue.js.Vue.js
O Vue.js é algo que estou esperando há muito tempo (daqui em diante vou falar sobre o Vue.js 2, que recebeu muitas melhorias em comparação com a primeira versão do Vue, e esta é a atual versão estável do sistema). Para mim, em termos de elegância e concisão, além de focar em soluções para problemas do mundo real, o Vue.js é a maior inovação em JS desde o dia em que fui surpreendido pelo Jquery em 2007. Se você olhar para os gráficos de popularidade do Vue.js., note que este ano ele não apenas agradou a mim:No Vue Github - o primeiro projeto JS de 2016 (entre nabos com códigos-fonte).Pela popularidade no Google Trends, o Vue.js em 2016 superou o React (é claro, essa é a temperatura média em um hospital muito grande e depende muito da solicitação formulada - um sinal indireto de popularidade).https://www.google.com/trends/explore?q=vue.js,react.js,angular.js OVue.js é um dos que mais cresce (em termos de comunidade ou pelo menos o número de curtidas no github e usuários das soluções Vue Dev Tools no chrome) JS em 2016, e tenho certeza de que essa não é apenas mais uma biblioteca moderna para descolados que mudam para uma nova estrutura JS a cada 3 meses, ou o trabalho do departamento de relações públicas é grande. empresa.O Laravel adicionou o Vue.js ao kernel, e essa é uma reivindicação séria.Profissionais do Vue.js
O Vue.js mantém um excelente equilíbrio entre legibilidade, capacidade de manutenção do código e o prazer dele, esse código, de escrever. Esse equilíbrio está localizado a uma distância aproximadamente equidistante entre React e Angular 1 e, se você observar a diretriz vue.js., notará imediatamente quantas idéias úteis ele emprestou desses sistemas.No React Vue.js, adotei a abordagem de componentes, adereços, um fluxo de dados unidirecional para a hierarquia de componentes, desempenho, capacidade de renderização no back-end e a importância do gerenciamento de estado adequado. O Vue.js retirou modelos similares do Angular1 com boa sintaxe e ligação bidirecional, mas apenas onde você realmente precisa e não permitirá que você atire imediatamente na perna (dentro de um componente). É muito fácil começar a escrever código no Vue.js - vi isso em nossa equipe. O Vue.js não requer nenhum compilador padrão, portanto, é muito fácil adicionar o Vue.js à sua base de códigos herdada e começar a copiar o hash do jQuery no código legível.A quantidade certa de magia
O Vue.js é muito simples de trabalhar, tanto em termos da abordagem centrada em HTML quanto do ponto de vista dos desenvolvedores de JS: você pode criar modelos bastante complexos sem perder o foco na tarefa de negócios, e o modelo HTML resultante geralmente é bem lido mesmo quando ele já é grande. A essa altura, como regra, você fez um bom progresso na solução do problema de negócios e pode reorganizar os modelos e dividi-los em componentes menores - neste momento, você vê toda a "imagem" do seu aplicativo muito melhor do que no começo. Minha experiência mostra que isso é significativamente diferente da abordagem que os programadores do React geralmente usam, e essa diferença economiza muito tempo e esforço para programadores que usam o Vue.js. Em React, você é forçado adivida os componentes em microcomponentes e microfunções no momento da redação da versão inicial "rascunho" do código; caso contrário, você estará literalmente enterrado em uma confusão de colchetes e HTML entre eles. No React, passo muito tempo polindo adereços e refatorando componentes super pequenos (que, é claro, nunca serão reutilizados) de novo e de novo, porque não vejo isso tão claramente quando de repente preciso mudar a lógica do código no meio do processo.Formulários
Trabalhar com formulários HTML no Vue.js é um prazer. É aqui que a ligação em frente e verso realmente ajuda. Mesmo em casos difíceis, não há problema, embora os observadores possam, à primeira vista, se parecer com o Angular 1. Um fluxo de dados unidirecional está sempre ao seu serviço quando você divide componentes.Tecnologia
Se você deseja compilação, linting, PostCSS e ES6 não são um problema . Os componentes de arquivo único parecem estar se tornando a principal maneira de gravar componentes públicos no Vue.js 2. A propósito, a idéia de CSS com escopo definido trabalhando em componentes de arquivo único fora da caixa é algo que parece realmente bom e pode reduzir a necessidade de regras estritas de nomeação de CSS classes e tecnologias como o BEM .Gestão estatal
O Vue.js possui um gerenciamento de estado bastante simples e útil por meio dos métodos data () e props () - eles funcionam bem no desenvolvimento real. Se a alma pede algo mais para a administração do estado, existe o Vuex (que, na minha opinião, é semelhante ao Mobx no React - o estado é mutável lá). Acho que uma boa porcentagem dos aplicativos Vue.js. não precisará de gerenciamento de estado por meio do Vuex, mas é bom ter uma alternativa.Desempenho
O tema é holístico, em geral, ambos reagem e o vue.js é rápido. Mas, no entanto, aparentemente, o vue.js, em média, é visivelmente mais rápido.Um link maravilhoso dos comentários no TodoMVC é executado com medições:eigenmethod.imtqy.com/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs~mol~react~vue~vanillajs#sort=fill#E aqui há contas mais detalhadas (da parte interessada) .Outra comparação de benchmark detalhada e inteligível:stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.htmlContras VueJS
Erros de modelo de tempo de execução
Maior: erros desagradáveis de tempo de execução nos modelos. Vítima pela conveniência de escrever código. Isso é muito semelhante ao Angular 1. O Vue.js consegue gerar muitos avisos úteis para o código JS: por exemplo, existem avisos quando você tenta alterar os objetos ou usar o método data () incorretamente, a influência positiva do React é muito perceptível aqui. Mas os erros do modelo de tempo de execução ainda são a fraqueza do Vue.js. Os rastreamentos de pilha de exceção geralmente são inúteis e levam a métodos internos do Vue.js. Nesse caso, nessa classe de erros e depuração, o JSX geralmente é mais agradável: devido à compilação “de JS para JS”, clicar em um erro no console do navegador geralmente leva exatamente ao local em que esse erro ocorreu no código.Bibliotecas
A infraestrutura do Vue.js ainda é bastante jovem. De fato, componentes estáveis da comunidade podem ser contados nos dedos, e muitos deles foram criados para o Vue.js. 1, e geralmente não é tão fácil para iniciantes descobrir para qual versão do Vue.js. uma biblioteca específica é criada. Esse problema é atenuado pelo fato de que você pode fazer coisas legais no Vue.js sem ter muita necessidade de bibliotecas de terceiros. Você provavelmente só precisa de uma biblioteca para solicitações do Ajax (o vue-resource seria uma boa opção se você não se importa com aplicativos isomórficos, caso contrário o Axios ) e provavelmente o Vue-router, que é considerado uma biblioteca com bom suporte do Vue.js.Comunidade que não fala inglês
Comentários em chinês no código da maioria dos repositórios públicos, e isso não é surpreendente: o Vue.js está se tornando uma solução muito popular na China (o Vue.js fala chinês)Projeto de uma pessoa.
Em vez disso, é um problema potencial do que real, mas às vezes você quer jogar pelo seguro. Evan Você é o cara que construiu o Vue depois de trabalhar no Google e Meteor. Laravel, é claro, também é um projeto individual, mas mesmo assim ele ainda tem muito sucesso, certo?Vue.js em Drupal
Isenção de responsabilidade: não planejamos usar o Drupal 8 tão cedo no Qwintry, já que estamos mudando para estruturas PHP mais modernas, rápidas e simples e Node.js., mas nosso código legado é Drupal. Como o site principal qwintry.com é executado no Drupal, era muito importante verificar o Vue.js na batalha aqui. Honestamente, não tenho orgulho de muitas seções do nosso código neste repositório, tentamos não entrar em lugares de destaque enquanto ele funciona, pelo menos de alguma maneira, mas esse projeto antigo com histórico está funcionando razoavelmente bem e gera nossa renda, por isso respeitamos, melhorá-lo e muitos novos recursos aparecem aqui. Aqui está uma lista das coisas que eu criei no Vue no Drupal: um formulário rápido de editor de entidades que inclui a geração de faturas de clientes e a edição rápida de listagens de produtos.Aqui foi necessário criar uma API JSON simples para carregar e salvar entidades - nada de especial, apenas alguns retornos de chamada. Dois painéis, por meio da API REST Saas dos produtos que usamos para nossa equipe de suporte, para que os operadores não precisem percorrer as páginas de administração de sites individuais para verificar as informações relacionadas a um cliente específico. Agora tudo isso está embutido no perfil do cliente em nosso site. Eu sei que muitos desenvolvedores de back-end ainda estão presos em 2010 com o sistema de kernel do Ajax Drupal. Sei bem o quão complicado o código Drupal pode ser quando você tenta criar algum tipo de formulário complexo de vários estágios usando a funcionalidade Ajax do kernel - é quase impossível manter esse código posteriormente. Sim, estou falando de você, ctools_wizard_multistep_form () e você,através da API REST Saas dos produtos que usamos para nossa equipe de suporte, para que os operadores não precisem percorrer as páginas de administração de sites individuais para verificar as informações relacionadas a um cliente específico. Agora tudo isso está embutido no perfil do cliente em nosso site. Eu sei que muitos desenvolvedores de back-end ainda estão presos em 2010 com o sistema de kernel do Ajax Drupal. Sei bem o quão complicado o código Drupal pode ser quando você tenta criar algum tipo de formulário complexo de vários estágios usando a funcionalidade Ajax do kernel - é quase impossível manter esse código posteriormente. Sim, estou falando de você, ctools_wizard_multistep_form () e você,através da API REST Saas dos produtos que usamos para nossa equipe de suporte, para que os operadores não precisem percorrer as páginas de administração de sites individuais para verificar as informações relacionadas a um cliente específico. Agora tudo isso está embutido no perfil do cliente em nosso site. Eu sei que muitos desenvolvedores de back-end ainda estão presos em 2010 com o sistema de kernel do Ajax Drupal. Sei bem o quão complicado o código Drupal pode ser quando você tenta criar algum tipo de formulário complexo de vários estágios usando a funcionalidade Ajax do kernel - é quase impossível manter esse código posteriormente. Sim, estou falando de você, ctools_wizard_multistep_form () e você,Agora tudo isso está embutido no perfil do cliente em nosso site. Eu sei que muitos desenvolvedores de back-end ainda estão presos em 2010 com o sistema de kernel do Ajax Drupal. Sei bem o quão complicado o código Drupal pode ser quando você tenta criar algum tipo de formulário complexo de vários estágios usando a funcionalidade Ajax do kernel - é quase impossível manter esse código posteriormente. Sim, estou falando de você, ctools_wizard_multistep_form () e você,Agora tudo isso está embutido no perfil do cliente em nosso site. Eu sei que muitos desenvolvedores de back-end ainda estão presos em 2010 com o sistema de kernel do Ajax Drupal. Sei bem o quão complicado o código Drupal pode ser quando você tenta criar algum tipo de formulário complexo de vários estágios usando a funcionalidade Ajax do kernel - é quase impossível manter esse código posteriormente. Sim, estou falando de você, ctools_wizard_multistep_form () e você,ajax_render !Ao mesmo tempo, esses desenvolvedores são aprimorados pelos requisitos de interfaces modernas, mas a complexidade da infraestrutura JS moderna os leva a uma depressão. Sim, eu me reconheço há um ano. Então pessoal, me escutem! Você não encontrará um momento e uma maneira melhores de melhorar suas interfaces do que no momento, pegue o Vue.js, coloque-o em sites / all / libraries, adicione-o com drupal_add_js () ao modelo e comece a escrever o código. Você ficará chocado com o quão mais fácil é manter um sistema no qual o Drupal é responsável apenas pelo JSON gerado quando todo o código do cliente, incluindo os formulários, é totalmente alimentado por Vue.js.Vue.js no Yii2
Curiosidade: O Yii foi criado pelo desenvolvedor em chinês Qiang Xue. Assim, pode-se chamar Yii + Vue.js uma pilha não apenas uma pilha, cujo nome é quase impossível de pronunciar na primeira tentativa, mas também uma pilha com herança chinesa (no bom sentido). Para a nova versão do Qwintry.com (ainda não publicada), escolhemos o Yii2, que, na minha opinião, é uma das melhores e mais rápidas estruturas PHP. Definitivamente, não é tão popular quanto o Laravel, que assumiu a liderança no mundo PHP, mas a pilha Yii2 está muito bem conosco.(embora observemos o Laravel de tempos em tempos, os desenvolvedores estão aproveitando e, é claro, uma infraestrutura mais madura em termos de bibliotecas). Estamos reduzindo gradualmente a quantidade de HTML que o Yii2 e o PHP geram, focando mais na API REST, que gera JSON para o lado do cliente, executando no Vue.js / Swift / Java. A abordagem API-first é usada na maioria dos modelos do Active Record no projeto. Aqui já estamos falando sério sobre a API e é por isso que gastamos muito tempo em boa documentação da API, mesmo que essa API não seja pública. Nas seções de código em que a parte HTML é gerada no nível PHP, usamos nossas próprias soluções e webpack para empacotar e implementar convenientemente os widgets Yii2, que, por sua vez, usam componentes de arquivo único do Vue. Com o PHP7 e o MySQL mais recente, o tempo de resposta do nosso back-end Yii2 JSON não é muito diferente do Node.js backends (estou falando de uma velocidade de resposta da ordem de 15-20ms), essas não são figuras cósmicas, francamente, mas isso é mais do que suficiente para nossas necessidades e, mais importante, é 10 a 20 vezes mais rápido do que aquilo que pode dar nosso antigo site Drupal. Ao mesmo tempo, este é um bom e velho PHP (e chato, talvez) com toda a força das bibliotecas do compositor e uma base de código estável. A capacidade de resposta das interfaces criadas no Yii2 & Vue.js é muito aceitável e, do ponto de vista da legibilidade do código, tudo está em ordem aqui também.A capacidade de resposta das interfaces criadas no Yii2 & Vue.js é muito aceitável e, do ponto de vista da legibilidade do código, tudo está em ordem aqui também.A capacidade de resposta das interfaces criadas no Yii2 & Vue.js é muito aceitável e, do ponto de vista da legibilidade do código, tudo está em ordem aqui também.Também usamos o Vue.js em vários projetos internos e externos, nos quais o back-end é executado no Node.js - não adicionarei nada novo ao anterior, tudo funciona bem.Conclusão
Escrevemos o código Vue.js todos os dias há cerca de 4 meses em vários projetos, e os resultados são impressionantes. 4 meses não é nada no mundo back-end, mas para o mundo JS esse é um período decente para o qual cinco estruturas nascem e morrem :) Vamos ver o que acontece a seguir. Acho que o Vue.js será a principal solução para o JS nos próximos 16 a 24 meses se o Evan You tomar as medidas certas, pelo menos entre as equipes de back-end e pequenas equipes de front-end. A pilha do React será mainstream em 2017, especialmente se o React Native continuar a crescer e melhorar no mesmo ritmo que é agora.UPD: Este artigo atingiu o topo HackerNews, e seguiu-se uma discussão útil (250 + comentários): news.ycombinator.com/item?id=13151317Em Reddit topo Webdev também visitado, 60+ comentários aqui. Opinião-comentário engraçado sobre o Angular2 a partir daí:Toda a documentação do Google é como ler documentos da Microsoft desde o início dos anos 2000.
"Montar um projeto Angular é um pedaço de bolo! Apenas certifique-se de que o mutador do protótipo de referência sem estado herda o objeto legado do carregador de memória base que implementa o provedor de serviços MODOK (não faz parte do núcleo: veja aqui para detalhes igualmente ilegíveis). Você estará pronto para compilar seu kernel Angular, tomando cuidado para usar o Webpack 2.3.9 (nota: não 2.3.8, como fornecido com o repositório). É tudo o que você precisa saber para começar um ótimo projeto Angular. Angular: tornando o desenvolvimento simples e divertido de novo! ”
Perguntas dos leitores:
JSX é legal e correto, mas você não é muito! Se você realmente deseja condições - programe seu componente If, estas são três linhas!É desagradável escolher uma estrutura e depois fazer essas coisas contra ele; todo novo desenvolvedor que vier ao projeto perguntará sobre essas decisões e, nos componentes de outras pessoas, seus olhos sempre tropeçarão na ternaridade.Além disso, se o componente escrito “testa” tiver problemas, os componentes internos serão sempre executados. Mas existem soluções mais interessantes: github.com/AlexGilleran/jsx-control-statementsEntão, o que você sugere, querida, agora você precisa deixar o React com urgência e reescrever tudo no Vue.js?Não não O React é uma excelente estrutura, e permite que você escreva códigos legíveis e suportados, e também uma grande quantidade de bibliotecas de alta qualidade já foram escritas para ele (e os microcomponentes e limitações do JSX, que eu “repreendi” acima, desempenham um papel positivo aqui, para bibliotecas públicas, isso é justificado), que não são para nenhuma outra solução JS. Se você e sua equipe estão satisfeitos com tudo no JSX e não se incomodam em digitar muito, talvez não faça sentido mudar para o Vue.js, o jogo simplesmente não vale a pena. Muitos amantes de JS recentemente adoraram pular de uma estrutura para outra. Não abuse, na minha opinião, é melhor gastar esse tempo em algo mais interessante que os usuários do seu projeto perceberão.Mas se você não conseguiu começar a usar o React por causa de ferramentas massivas e outras dificuldades, e seu código se depara com uma confusão lenta de jQuery ou Backbone, o Vue.js pode ser uma ótima opção, não acadêmica, simples e concisa.Eu não li o artigo inteiro, mas na manchete você disse algo negativo sobre imunidade, provavelmente não é ortodoxo por causa de sua inexperiência e estupidez, não entende como é maravilhosa a abordagem funcional!Vamos separar a imunidade como um paradigma funcional (respeitamos muito a abordagem funcional, o conceito de imunidade e a pureza das funções) e o estado atual do mundo JS e de suas bibliotecas. Se um desenvolvedor, depois de ler o blog do Facebook, pega alegremente o Immutable.js e o coloca em produção, e então percebe que ele não tem uma doca muito boa, Lodash e todo o resto do código escrito pela geração anterior de desenvolvedores não trabalham com ele (sim, eu sei sobre invólucros imutáveis no lodash, obrigado) e, portanto, o desenvolvedor falha no prazo - isso significa que o desenvolvedor não comprou o paradigma funcional, mas sim o hype em torno da biblioteca específica. Não pense que se o Facebook tiver problemas reais que eles resolvam usando o Immutable.js, isso significa que você terá problemas de ordem semelhante na sua página de destino ou no SPA.Provavelmente nãoseus investidores ficarão sem dinheiro, você precisará implementar os recursos de trabalho o mais rápido possível, e é suficiente que o código seja normal e não sofra alterações quando não for necessário, não é necessário usar o Immutable.js para isso (leia a opinião sobre Immutable.js, por exemplo, aqui ). Separadamente, observo que um grande número de desenvolvedores de JS, cujas opiniões eu vi como o principal recurso do Immutable.js, são chamados não de pureza e confiabilidade do código resultante, mas - atenção! - aumento da produtividade (estamos falando de comparações rápidas de estruturas)! Algo neste mundo está errado se as pessoas estão colocando uma parte funcional desse nível em prol da melhoria do desempenho em seu projeto. Parece que a moda voltou a intervir ...Se você quiser simplificar sua vida, pare de mudar sua condição, mude para adereços, e essas coisas simples melhorarão sua vida agora.