Web versus desenvolvimento de desktop - o desenvolvimento da web é pior? [fechadas]


29

Como um desenvolvedor de desktops de longa data que procura fazer nosso primeiro aplicativo da web em larga escala, quais são os prós e os contras de fazer o desenvolvimento da web?

O desenvolvimento de um aplicativo Web é muito pior do que o desenvolvimento de um aplicativo de desktop? Por exemplo, é mais tedioso ou irritante? O tempo de comercialização é muito pior? A plataforma da Web é excessivamente limitada? Se a resposta para qualquer uma dessas perguntas for sim, então por quê?

(E como se compara o desenvolvimento de um aplicativo Flash ou Silverlight?)


5
Não votei para fechar, mas acho que seria mais construtivo se pudesse ser reutilizado no ponto de vista de desenvolvimento da Web versus desenvolvimento de desktop.
21420 Josh K

K: Ok, tentei reformular a pergunta sem invalidar as respostas existentes. Obrigado.
Josh Kelley

Respostas:


26

Não

É doloroso se você não sabe o que está fazendo ou não planeja corretamente, mas isso é verdade em qualquer desenvolvimento. É mais fácil compactar o aplicativo em um aplicativo de desktop, mas você perde a acessibilidade fornecida pela codificação de um aplicativo Web.

Eu faria a escolha entre desktop e web com base no uso desejado. Vejo muitos aplicativos escritos na Web que não deveriam ser porque não sabem como codificar aplicativos de desktop. Não vejo muitos aplicativos de desktop que devam ser baseados na Web e acho que isso é algo a considerar. Se você precisar de armazenamento centralizado, acessibilidade remota e características da interface do usuário, com certeza .

Não posso comentar sobre o Flash ou o Silverlight porque não os utilizo.


5
Eu odeio ser que cara, mas ... :s/loose/lose/:)
dr Hannibal Lecter

@dr Hannibal: Corrigido. Às vezes, toque duas vezes nas teclas. ;)
Josh K

4
@dr Hannibal: Há uma dissonância cognitiva tal que vem das palavras "eu odeio ser que guy" provenientes de "Hannibal Lecter" :)
Skilldrick

25

Como mencionado por outros, é uma questão de troca e de ter o conhecimento certo.

A única armadilha que você pode querer considerar é esta: você menciona na sua pergunta que considera a Web como tendo uma "plataforma cruzada" como uma vantagem. Mas isso realmente? Pense da seguinte maneira: se você desenvolver algo para a área de trabalho, precisará definir a lista de plataformas e seus requisitos para dar suporte.

Não se engane, é o mesmo para a web. E mesmo que já seja tremendamente mais simples do que costumava ser, se você criar um aplicativo público amplo, terá que lidar com todas as versões possíveis de todos os navegadores da web. E se for mais um aplicativo corporativo, prepare-se e prepare-se para elaborar os requisitos das plataformas de navegador suportadas com muita precisão.

Não pense que você evitará ter hacks específicos da plataforma aqui e ali, se criar algo significativo.

E então as partes divertidas. O que e melhor? Navegadores que se atualizam quase transparentemente com muita regularidade como o Chrome? Ou os que lançam atualizações de segurança apenas mensais e os principais recursos a cada idade da pedra (como o IE)? A resposta não é tão óbvia quanto você imagina, porque algumas dessas atualizações "transparentes" frequentes podem quebrar o seu código e você precisará segui-las e reagir imediatamente. Ou fique de olho nas pré-versões beta e dev durante o desenvolvimento e o teste. Para todos os navegadores que você disse tolamente que queria apoiar (boa sorte).

Ah, e não vamos esquecer as considerações da interface do usuário. Você também enfrentam a alegria de decidir se você quer uma interface de usuário consistente ACROSS todas as suas plataformas de destino, ou uma interface de usuário consistente COMplataforma de destino de cada host. Veja todos esses pequenos botões que você pode ver nas páginas da web? Deseja que sejam exatamente iguais em todos os lugares ou que se integrem ao ambiente usado por seu usuário? É claro que esse problema não é novo e existe para outros modelos de desenvolvimento, mas parece ser mais importante aqui e depende do tipo de usuário que você deseja e do que ele espera. O usuário final público tende a querer que você se integre à plataforma dele - mas ainda assim quer que você "uau!" eles com coisas sofisticadas - enquanto o usuário corporativo deseja algo que se parece com um aplicativo de desktop. E as plataformas móveis tiveram uma nova dimensão para tudo isso.

Nos últimos 2 parágrafos, uma idéia comum é às vezes empacotar um navegador da Web pré-configurado com o instalador, que se conecta ao seu aplicativo da Web (hospedado localmente ou na Web). É ótimo porque você controla a frequência da atualização e pode "congelar" o estado e sabe exatamente no que apoiar e testar. Além disso, você pode adicionar itens interessantes, como extensões de usuário dedicadas. Por exemplo, empacotar um Chromium "congelado" com pequenas extensões do Chrome que você desenvolveu para facilitar o uso do aplicativo da web para diferentes tipos de usuários pode ser extremamente agradável. Por outro lado ... agora você é responsável se ocorrer uma violação de segurança porque congelou o ciclo de lançamento e seu aplicativo não se beneficiará de melhorias na velocidade (se houver).

Como muitas coisas, é um machado de dois gumes.

Nota: Eu tenho um forte viés contra a Web por ser basicamente uma grande pilha de tecnologias semi-cozidas (e sou educado aqui), até as camadas OSI, nas quais continuamos adicionando camadas de porcaria que escondem os problemas subjacentes sem realmente resolver ou consertá-los.

Dito isto, sou a favor da Web por sua natureza onipresente como plataforma. Acho que a mudança da sua empresa é (provavelmente) a correta. Depende do seu mercado-alvo e das plataformas que você deseja, obviamente. Se você deseja expor algo como um serviço, provavelmente estará pronto (embora também não seja necessário). Caso contrário, talvez não haja muitas razões para isso.

Hmm, e espere alguns desenvolvimentos divertidos no futuro agora que mais variantes leves de sistemas operacionais existentes continuam gerando ambientes móveis (netbooks, smartphones, PDAs, tablets, eBooks ...), com mais ênfase no uso de navegadores embarcados leves. .. mas com todo o seu novo compartilhamento de falhas na renderização da interface do usuário.

Em relação às tecnologias baseadas em plugins ... eu diria que se afaste delas. Eles aumentarão o poder do seu aplicativo, mas limitarão sua penetração no mercado. Em alguns casos, você verá isso como uma vantagem em termos de suporte entre plataformas, até que uma nova plataforma se recuse repentinamente a apoiá-los. Os padrões da Web estão aqui por um motivo (tenha cuidado para não ficar muito animado com tudo no HTMl5, ou isso poderá explodir na sua cara).


EDIT: outras coisas a considerar ...

Recrutamento

É extremamente difícil encontrar desenvolvedores web experientes. Você pensaria que há um grupo deles, mas eles estão perdidos em um imenso conjunto de pessoas bem incompetentes que acham que ter conseguido escrever 700 linhas de JavaScript / ECMAScript para implementar alguma validação em seus formulários é o fim de tudo e tudo o que pode ser alcançado em termos de habilidades de alto nível.

Não estou brincando, ultimamente, minha primeira pergunta para todas as entrevistas de desenvolvimento da Web é como declarar uma variável e, em seguida, se há uma diferença entre usar varou não (dependendo de como elas respondem). É deprimente. Acho muito mais difícil encontrar um desenvolvedor web médio ou avançado do que encontrar um desenvolvedor de desktop médio ou avançado.

Percepção

Ninguém nunca o considerará seriamente quando você disser "Sou desenvolvedor de web". É para uma subclasse de programadores, desenvolvedores, não é? Os que você ignora e zomba de longe, e não se junta quando vai tomar café. :)

Isso é obviamente falso, mas tudo se resume ao fato de você se desenvolver para um ambiente que é gerenciado principalmente por você. Os navegadores corrigem sua marcação danificada, seus estilos danificados e até corrigem seus scripts danificados para alguns deles, além de otimizá-lo para você, por favor. E se você é um desenvolvedor web, as pessoas não assumem que você tem uma pista sobre programação de nível inferior; portanto, você deve ser um idiota completo, certo?

E então eles percebem o quão loucamente complexo o ECMAScript pode ser, mas se recusam a revisar sua opinião. Porque é web. Não gostamos intrinsecamente, apenas gostamos do que isso nos permite fazer.


-2, 10 ... Vejo que promoveu alguma controvérsia;)
haylem

As diferenças entre navegadores tornaram-se cada vez menos um problema. Certamente, há pequenas inconsistências na maneira como eles lidam com CSS e outros enfeites, mas na maioria das vezes, nunca tive um grande problema com um navegador moderno. A menos que você está certo na borda do sangramento com HTML5, <canvas>e coisas assim ...
Dean Harding

6
"Nota: Eu tenho um forte viés contra a Web por ser basicamente uma grande pilha de tecnologias semi-cozidas (e sou educado aqui), até as camadas OSI, nas quais continuamos adicionando camadas de porcaria que escondem os problemas por baixo sem realmente resolvê-los ou corrigi-los ". - VOCÊ É EU?????
Bobby Tables

2
Trabalhei com dois caras que são verdadeiros gurus do desenvolvimento da web, fazem coisas incríveis e a usam como uma plataforma de desenvolvimento de software séria. Eles têm meu profundo respeito. Mas são apenas duas nos últimos 15 anos. O resto ... bem, uma vez eu consegui uma vaga como "especialista" em Perl só porque meu código de amostra estava estruturado, e não o espaguete ao qual o entrevistador estava acostumado; naquele momento, minha experiência genuína em Perl cabia em um dedal.
Bob Murphy

2
+1 para ECMAScript sendo bom, ruim e chamado ECMAScript.
Alan Pearce

14

Como alguém que lida com ambos (mais desktop do que web): de longe, minha maior reclamação é a sensação de "falta de clareza geral" no desenvolvimento da web. Mesmo com as melhores ferramentas e estruturas, as abstrações ainda são muito vazias e você está constantemente lidando com o fato de estar executando um protocolo sem estado.

Outro aborrecimento relacionado é a mistura de tecnologias usadas para implementar aplicativos da web. Não existe um ambiente e linguagem agradáveis, monolíticos e modulares nos quais tudo possa ser feito. Mesmo aplicativos da Web relativamente simples exigem que você codifique as coisas em várias linguagens de programação, script e marcação separadas.

Então, como resposta geral: SIM , é realmente tão ruim assim. Pelo menos, se você vem de um plano de fundo tradicional da área de trabalho, onde está acostumado a codificar coisas em um ambiente limpo e sem costura, usando uma tecnologia e plataforma em que tudo é bastante linear e bem definido. A melhor maneira é simplesmente não tentar pensar nisso como o mesmo campo. Se você inconscientemente espera que o desenvolvimento da Web seja "como o desenvolvimento de desktop", sempre parecerá muito desagradável e irritante.


4
A razão de parecer "geralmente desajeitado" talvez seja porque você estava usando estruturas que tentavam "abstrair" ... o que é a web? A web não tem estado. Não importa o quanto as "formas da web" no ASP.NET desejem fazer você pensar o contrário, nunca se esqueça de que é sem estado. Quanto mais rápido um desenvolvedor aceita isso, como uma verdade imutável, mais rápido eles criam aplicativos Web de qualidade.
Jason Whitehorn

1
+1, bem dito. Mesmo com estruturas como o Rails, que deveriam ser a solução para escrever tudo em uma única pilha de tecnologia, eles conseguem estragar tudo, alterando as práticas recomendadas do RJS para "JS Discreto".
Jas

11

o maior repensar da área de trabalho para a web é: o aplicativo da web é inerentemente sem estado

descobrir essa parte, e você é bom.


navegador importa?
JeffO 9/11/2010

@ Jeff inconsistências cross-browser são irritantes, mas não é realmente significativo
Steven A. Lowe

4
Você precisa escrever para navegadores reais (algumas inconsistências), Internet Explorer (mais inconsistências) e talvez o filho do diabo (IE6).
TRiG

2
@Malfist: Se você não tiver cuidado, com esta abordagem (sessões apátridas + = stateful) você poderia projetar um emu com um motor a jato aeronaves trancada, quando você originalmente desejava uma águia;)
Piskvor

1
@ Jim G: é claro que é. Mas as diferenças entre navegadores e outros são minúsculas em comparação ao passar do design de aplicativos com estado para o sem estado.
Steven A. Lowe

5

Grande parte do tédio provém do trabalho necessário para fazer tudo funcionar em todos os navegadores. Como você provavelmente não precisa estar no limite, pode aproveitar o trabalho realizado por outras pessoas, escolhendo uma estrutura da Web adequada em vez de manusear a sua própria.

Qual usar, depende fortemente de qual ambiente de linguagem você está acostumado atualmente. Você pode editar a pergunta para fornecer essas informações.


2
Os problemas de compatibilidade do navegador são uma dor gigantesca, é verdade, mas para equilibrar isso, não se esqueça de que ele está se comparando ao desenvolvimento de desktops, onde você precisa lidar com diferentes versões de sistemas operacionais, bibliotecas, etc.
Carson63000

@Carson, se eles desenvolvem o desktop Java, essa dor é realmente mínima. Talvez seja muito pior para a API .NET ou Win32.

2

Não, os aplicativos da web têm vantagens e desvantagens diferentes dos aplicativos de desktop. Cada um tem suas forças na minha mente. Embora haja pontos fortes como uma única implantação, existe o compromisso de saber quais navegadores você suporta e que resolução de tela você espera que o cliente tenha? Embora você tenha controle sobre o hardware do servidor, há a questão de quanto tráfego você espera e qual será o seu nível de escala? Para aqueles que desenvolvem a web há anos, esses pontos podem ser doloridos, como eu imaginaria que você tem algumas tarefas de desenvolvimento que considera uma grande dor, não?

Um aplicativo Flash pode ou não ser um aplicativo da Web para mim. Algo como o AIR pode fazer com que algumas coisas em Flash sejam executadas na área de trabalho agora e alguns aplicativos são criados com base nisso, por exemplo, Twhirl, portanto não é tão fácil assim.


2

O desenvolvimento da Web não é necessariamente pior , é apenas muito diferente.

Uma das coisas que separa o desenvolvimento web do desenvolvimento de desktop é a infinidade de tecnologias radicalmente diferentes que você precisa dominar para desenvolver um aplicativo decentemente complexo. Quero dizer, você basicamente precisa ter um forte conhecimento de:

  • HTML
  • Javascript
  • CSS
  • Alguma linguagem do lado do servidor (Java / PHP / qualquer que seja ...)
  • Um RDBMS (ou alguma tecnologia de armazenamento persistente)
  • ... e possivelmente muitas outras coisas como Flash, Silverlight etc.

Considerando que, com o desenvolvimento de desktop, você geralmente trabalha com um conjunto de tecnologias muito mais monolítico. Por exemplo, o desenvolvimento de um aplicativo Java basicamente requer que você conheça Java, e é isso. (Obviamente, isso é uma simplificação, mas o ponto é que o desenvolvimento da Web expõe você a uma gama muito mais ampla de tecnologias radicalmente diferentes que precisam trabalhar juntas para formar um aplicativo em funcionamento.)


1

Não

Desde que você escolha as ferramentas certas, o desenvolvimento da Web é tão limpo e fácil quanto o desenvolvimento da área de trabalho.

As APIs da web (html, CSS, Javascript e DOM) são equivalentes à API do win32. Eventualmente, tudo se reduz a esse nível de API, mas você fica louco se programar diretamente em cima dela sem uma biblioteca para abstrair a confusão, a verbosidade e a inconsistência.

Portanto, tenha cuidado com sua escolha de estruturas. Alguns problemas são auto-infligidos escolhendo ferramentas ruins (por exemplo, problemas de compatibilidade do navegador).

É possível ter uma plataforma de desenvolvimento web limpa e consistente, com um único idioma. Por exemplo, se você deseja que ele seja "todo java o tempo todo", você pode usar o GWT e escrever o código do lado do cliente e do lado do servidor em Java. Ou, se preferir que seja tudo javascript, você pode escolher algo como Ext JS para o cliente e node.js para o servidor.


0

Eu ouvi isso descrito como "... a desgraça da minha existência" e eu concordo. Me ofereceram $$$ por hora para fazer o desenvolvimento da Web em HTML e eu a rejeitei. É muita dor. Passei a maior parte do tempo em HTML e recentemente comecei a trabalhar com a "plataforma Flash". É uma das estruturas mais sofisticadas que eu já vi e ninguém sabe disso. Quando as pessoas criam o Flash, elas pensam no Flash há 10 anos. Cresceu ... muito. Eu amo escrever software novamente.

Ainda tem suas desvantagens. Às vezes, os erros permanecem para sempre, mas melhoram (obrigado Steve J.).

BTW Há uma grande escassez de desenvolvedores Flex. Fui abordado por tantas empresas que está doente. Se você conhece o seu CS, passe os próximos 6 meses ou mais aprendendo Hard Flex, em seguida, ligue para mim. Vou repassar todas as ofertas de emprego que tenho que recusar.

Atualização: o suporte a vários navegadores é o principal ponto problemático. O que funciona em um navegador não funciona em outro ou, mas não em uma versão anterior.

O processo é mais ou menos assim: - obtenha o design do site - tente recriá-lo em um navegador de destino (isso pode ser difícil) - mostre o cliente - o design das alterações do cliente - raspe todo o trabalho de layout que você fez originalmente - obtenha funcional - o cliente aprova - fazê-lo funcionar em outros navegadores. Esta é a parte mais difícil. Existem bugs obscuros o tempo todo. Você encontrará recursos que os navegadores anteriores não suportam, como cantos arredondados. Você tentará reutilizar seu código e css, mas isso rapidamente se fragmentará. Simplesmente pode se tornar alta manutenção muito rapidamente. Adicione animações e os navegadores mais antigos engasgam.

O cliente fará alterações. Você acabará gastando todo o seu tempo fazendo "o que deveria ser coisas simples" e odiar sua vida. Você se tornará um guru e saberá coisas que não quer saber. Sei que parece dramático, mas não estou embelezando os problemas que você enfrentará. Estruturas tornarão mais fácil. Se você persistir no trabalho em HTML, prepare-se para recriar um de seus sites favoritos em HTML, certificando-se de combinar o design e a funcionalidade em todos os navegadores compatíveis. Afaste os problemas que encontrar antes de começar um trabalho. Problemas como as melhores ferramentas de design, as melhores estruturas de javascript, as melhores ferramentas de depuração, os melhores IDEs etc.


Você poderia editar sua resposta para explicar por que a considera uma desgraça para sua existência?
Josh Kelley

Atualizei minha resposta acima

1
Três dólares por hora? Não é à toa que você recusou, isso é mesmo salário mínimo hoje em dia? ;)
Piskvor
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.