quarta-feira, 20 de agosto de 2014

Olha, nenhum cliente! Não é bem assim: o longo caminho para a Vim webbified


O guia essencial para transformação de TI


Programação da Web, Pt. III O aspecto mais revolucionário de todas as mudanças que ocorreram em desenvolvimento web ao longo das duas últimas décadas tem sido no navegador da web.


Normalmente pensamos em navegadores como promover a inovação na web, fornecendo novos recursos. Na verdade, esta é a principal fonte de novos recursos na web.







Por exemplo, a Microsoft lança uma versão do Internet Explorer, com suporte para iframes, XMLHTTP mais tarde (que Mozilla e outros pegar na forma do XMLHttpRequest) e assíncrona JavaScript nasce. Fora do que vem a capacidade de construir muito mais aplicações web complexas, como o Gmail.


Há, porém, uma outra maneira menos óbvia em que os navegadores têm vindo a impulsionar a inovação, especialmente nos últimos cinco anos -, dando desenvolvedores web ferramentas de desenvolvimento cada vez mais poderosos construíram para a direita no navegador da web.


Na verdade, é perfeitamente possível a web se tornou mais sofisticada na proporção da sofisticação das ferramentas disponíveis para a escrita, teste e depuração de HTML, CSS e JavaScript.


Será cada vez mais complexas e sofisticadas aplicações web de hoje ser possível, sem ferramentas de depuração disponíveis nos navegadores da web? Será Web Component experimentos conduzidos de hoje seria possível sem as ferramentas de desenvolvedor do Chrome, Firefox, Opera e IE? Bem, provavelmente eles ainda existem, mas seria muito mais difícil e demorado para construir.


Once Upon a navegadores de tempo oferecidos desenvolvedores web uma única ferramenta de desenvolvimento: view source.


Enquanto view source é uma ferramenta revolucionária - Eu não estou ciente de qualquer outra plataforma de desenvolvimento em que você pode olhar para o código por trás do aplicativo com o simples clique de um menu - é uma ferramenta de aprendizagem, e não uma ferramenta de construção. HTML, CSS e JavaScript arquivos de origem pode ser muito instrutivo, mas a fonte da vista é de pouca ajuda quando vem a escrever e testar a sua própria marcação e scripts.


Para escrever e testar seu próprio código, particularmente JavaScript, você precisa encontrar uma maneira de controlar o ambiente de tempo de execução do navegador - a capacidade de inserir pontos de interrupção, pausa código e percorrê-lo linha por linha para encontrar bugs e melhorar o código.


O primeiro grande esforço para dar aos desenvolvedores que tipo de direito poder dentro do navegador web foi Firebug. Inicialmente um add-on para o Firefox, o Firebug foi escrito em 2006 por Joe Hewitt - um dos criadores originais do Firefox. Existem algumas ferramentas para desenvolvedores do navegador que antecedem o Firebug. Internet Explorer 6 teve um add-on que mostrou o DOM e algumas outras informações sobre a página. E na mesma época Firebug lançado, WebKit introduziu o seu próprio Inspector WebKit, mas foi inicialmente limitado à inspeção HTML e CSS e faltava o JavaScript recursos encontrados no Firebug.


Firebug mudou o mundo do desenvolvimento web de várias maneiras. Em um nível prático, tornou muito mais fácil de escrever e depurar JavaScript, bem como inspecionar o DOM e até mesmo ver quais estilos foram aplicados a um nó HTML particular. Google levou essas idéias e correu com eles quando lançou seu navegador Chrome com seu conjunto amigável com o desenvolvedor de ferramentas. Hoje não há navegadores de desktop web sem ferramentas para desenvolvedores. Sim, até mesmo o IE 10 + tem algumas grandes ferramentas embutidas para os desenvolvedores.


Mas Firebug, WebKit Inspector e as ferramentas de desenvolvedor do Google Chrome representou uma mudança muito maior na forma como a web é construído - ferramentas para desenvolvedores no navegador movido a tarefa de construir as páginas de IDEs independentes separadas como o Dreamweaver da Macromedia / Adobe ou (tremor) Microsoft FrontPage para o navegador da web atual. Dreamweaver ainda existe, mas tem grande parte caiu à beira do caminho. Estes dias você seria duramente pressionado para encontrar um artigo ou tutorial sobre o desenvolvimento web que sequer menciona-lo.


Hoje você pode construir aplicações web inteiras sem nunca deixar o navegador da web.


O pacote de desenvolvedor nas versões mais recentes do Chrome, Opera e Firefox são compostos de várias dezenas de ferramentas que cobrem tudo, desde inspetores DOM para a rede cachoeiras para linha do tempo para os auditores integrados de velocidade página. Há painéis de codificação, consoles de JavaScript, profilers memória, editores de texto integrados (incluindo editores com Vim e Emacs apoio keybindings ) - até mesmo captura de tela e de cores conta-gotas na versão mais recente do Firefox.


Nos casos em que as ferramentas de pacotes não são o suficiente há uma abundância de complementos do navegador para estender seu alcance. Quer um shell básico em seu navegador? Basta pegar o Terminal Devtools add-on para o Chrome. Que tal um editor CSS visuais , um auditor acessibilidade ou mesmo todo um cliente FTP / SFTP ?


Há um embaraço de riquezas à espera de desenvolvedores web em navegadores atuais. Mas, enquanto as ferramentas de desenvolvimento de hoje baseados em navegador são fantasticamente poderoso e continuam a chegar a um ritmo quase esmagadora, desenvolvimento de sites diretamente no navegador é ainda mais difícil do que deveria ser, em muitos aspectos.


Oy, de novo com o servidor


Mesmo as coisas aparentemente simples como usar o editor de sua escolha não é inteiramente possível. Por exemplo, enquanto você pode obter um pouco do poder de Vim ou Emacs no seu navegador, você certamente não pode obter tudo isso. Mozilla tem demonstrado uma prova de conceito que permitiria que um editor de texto externo para controlar o Firefox através de alguns scripts Python , mas esse projeto nunca foi enviado, sua situação atual não é clara.


Alguns desenvolvedores argumentam que teria sido melhor colocar runtime do navegador em seu editor de texto, em vez de o contrário, mas neste ponto que parece improvável que isso aconteça.


Também há ainda uma enorme desconexão entre as ferramentas usadas para escrever e código do lado do cliente de teste (como JavaScript e CSS) e as ferramentas do lado do servidor que realmente enviar este código para o browser. Essa desconexão é parte da razão pela qual o desenvolvimento web moderna é como um pântano de ferramentas de terceiros.


Considere, por exemplo, o aparentemente simples processo de escrever um pouco de JavaScript para um tema WordPress. Enquanto você pode escrever, editar e depurar o JavaScript nas ferramentas de desenvolvedor do Chrome ou Firefox, você ainda precisa de um servidor local para processar a página WordPress seu JavaScript está tentando manipular, em primeiro lugar.


Com alguma sorte, no entanto, essa desconexão será um dos próximos grandes áreas fabricantes de navegadores atacar. Imaginem um painel de ferramentas de desenvolvimento que pode atuar como um servidor simples, basta apontá-lo para uma pasta e ele cuida do resto.


Ferramentas como o Node.js (se extraído do motor JavaScript do Chrome) poderia oferecer uma maneira de incorporar servidores simples, conecte o navegador para suas ferramentas de construção, pré-processadores e até mesmo seu editor favorito.


Podemos esperar. ®







via Alimentação (Feed)

Nenhum comentário:

Postar um comentário