[quote=JoseIgnacio][quote=matheuslmota]
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?[/quote]
Facebook não ganha dinheiro quando programadores compilam código mais rápido.
[/quote]
[quote=javaflex]
Tudo depende do caso mesmo, mas nunca passei por um caso de ter a necessidade de ser nativo. O maior erro é fazer algo nativo sem necessidade.[/quote]
Sim, do ponto de vista do esforço do programador. Mas do ponto de vista do Facebook foi ter achado que não era necessário fazer nativo.
Não sei se o corte é assim tão limpo e as gigantes não estão correndo atrás.
O Dart é uma unificação para toda a parte Web do google e muitos dos aplicativos do Google (como o Google+) é feito com Dart. É meio que obvio que não é possivel criar uma aplicação rica com as do google com javascript puro e nem com jquery. É preciso mais. Certo que o Dart não roda no android, como disse antes, as metaplataformas são uma coisa nova que ainda está sendo explorada. Contudo o GWT que compila para javascript e o Dart que compila para javascript e a V8 do crome sendo a melhor VM de ajavascript , fala muito sobre o Google. Para eles o que interessa é o browser e não é por acaso que tudo acaba em javascript. Inclusive o android tem uma component de browser que roda javascript. A integração está lá.
A microsoft tem o .net. O Windows 8 é suporto ser o mesmo para qualquer plataforma, mas com dois modos de operação. Pelo menos a plataforma de dev é a mesma : .net
A Apple aposta no objective-c ou melhor no Xcode, que é um IDE completo tanto para ios como OSX.
Cada uma dentro de casa adota uma politica que no fim se resume a unificar. O ponto é que nenhuma delas tem interesse em que haja uma meta-plataforma que permite às pessoas serem independentes deles. É a volta ao antigo bordão “o codigo é meu, se queres copilar, usa as minhas ferramentas”. E por isso que o java sofre , em certa medida o flash também. Porque eles sempre foram “roda em qualquer coisa”. Mas agora, os grandes não querem mais se preocupar com isso. E querem as pessoas se fidelizem. Ou seja, se vc aprende .net é para microsoft e pronto. A microsoft não está interessada em correr .net no linux, quanto mais no OSX e assim vai.
Mas quem não pertence nas grandes precisa do mesmo fator de economia que as grandes utilizam. Por isso começam a surgir cada vez mais meta-plataformas. Mas o negocio ainda não está afinado. Esta batalha foi ganha pelos nativos, mas a guerra ainda não acabou. Um outro ramo que também gerou algum incentivo foi o ramo financeiro e cientifico em geral. Com experiencias como as do cern com baldes e baldes de dados avuslsos é preciso alguma coisa que seja eficiente em termos de performance e moldável em termos de modelo de dados para dar vazão a essas analises - o famoso big data. Então aparece o NoSQL e linguagens como scala que trazem paradigmas diferentes para resolver problemas novos. Este é um problema com que as grandes não lidam e nem têm mercado, mas tem muita gente ai precisando.
Fora do mobile e como plataformas Java e .NET não deixam espaço para ninguém neste momento. E é muito interessante olhas a historia destas plataformas e como as escolhas foram feitas e aconteceu a evolução.
Mas ai vemos um monte de linguagens tentado rodar nestas plataformas. Scala sendo a mais relevante no momento. Mas para R e Python têm alguma coisa a dizer ainda e quando ha calculos envolvidos cai-se muitas vezes no .net + python , por exemplo.
Nos mobiles ainda temos - tirando os esquemas tipo PhoneGap - o nativo comandando. Mas acho que não é assim tão relevante para a industria como um todo, pois para cada App existe um server e esse server não corre em android nem OSX. Corre em java ou .net qual alguma linguagem Z que nem importa muito, porque no servidor o que mais importa é o framework. Pode até ser um Rails… O que quero dizer com isto, é que não serão as linguagens mobile que irão mudar o mundo. Pelo menos enquanto essa mesma linguagem não existir fora do mobile. O JME 3 e O FX eram/são a aposta da Oracle para retomar os ganhos nesse mercado e eles estão chegando lá. Talvez quando isso for uma realidade ao alcance de qualquer um de nós, essa papo de ir para nativo vai mudar. É o mesmo que antes quando o pessoa dizia “se quer performance use C++ em vez de java”, hoje o java supera a performance do C++. Dizer hoje, vá para nativo porque o HTML 5 não dá performance é a mesma coisa.
[quote=sergiotaborda]
Hoje a resposta mais conservadora ainda é : vai para web, usa javascript e sê feliz. E ai entram outras opções como Draft que compilam para javascript. Porque para fazer aplicações complexas end-to-end em javascript é muito complicado. javascript tem herança e tudo isso, mas ser fracamente tipado atrapalha e não haver uns construtoros mais simples para criar a herança, tb. [/quote]
Acho que não existe uma resposta padrão, depende do tipo de aplicação.
Se for algo simples e sem muita sofisticação ainda vai, mas qualquer coisa que requer processamento mais intensivo (ou que precisa acessar recursos do aparelho) JavaScript ou Java não tem nenhuma chance. Nesse caso nativo é o único caminho.
[quote=sergiotaborda]
Não é por acaso que as grandes estão apostanto em novas linguagens que oferecem novas plataformas. É porque é mais barato assim. Quem enxergar isso primeiro e se aproveitar disso primeiro, vai ganhar o mercado primeiro.[/quote]
A não ser o Facebook que tentou fazer isso e quebrou a cara.[/quote]
É considerado quase um fato que seja lá o que for o “próximo Facebook”, vai ser puro mobile.
Ou seja, não só é relevante pra indústria, como está mudando substancialmente a forma como construímos software no servidor (+ APIs restful para servir clientes nativos, - Flash).
[quote=JoseIgnacio][quote=javaflex]
Tudo depende do caso mesmo, mas nunca passei por um caso de ter a necessidade de ser nativo. O maior erro é fazer algo nativo sem necessidade.[/quote]
Sim, do ponto de vista do esforço do programador. Mas do ponto de vista do Facebook foi ter achado que não era necessário fazer nativo.[/quote]
A questão é, enquanto não houver necessidade não se faz nativo, tendo um layout responsivo não se gasta para fazer outra aplicação que atenda também a mobilidade. E quando for realmente necessário usar recurso avançado do dispositivo ai sim entra investimento para se criar uma app nativa. Ficando claro isso com os clientes. Facebook é um caso que nem entro em discussão, coisas globais devem rolar estratégias astronômicas.
sim; pelo simples fato de você poder vender o sistema que você fizer sem burocracia; também investi em um mac apenas para aprender objective c, e poder vender o meu trabalho mais facilmente; mas ainda estou na fase dos estudos da linguagem, não me arrependo e acredito que seja muito promissor;
[quote=matheuslmota][quote=juliocbq][quote=JoseIgnacio]
A não ser o Facebook que tentou fazer isso e quebrou a cara.[/quote]
Tem um texto dele falando que se arrependeu de fazer a aplicação do facebook como sistema híbrido. A melhor alternativa sempre seria nativo de plataforma.[/quote]
Até onde eu sabia o Facebook era feito em PHP e através de uma ferramenta desenvolvida por eles o código-fonte era convertido para C++. Por que o pessoal do Facebook se arrependeu?[/quote]
Desculpa, não especifiquei. Ele quis dizer referente a plataforma android. Diz que a solução web não foi a mais adequada comparada com a nativa.
Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.[/quote]
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?
Sérgio, sobre o esquema do html5 o problema não é performance mas o custo(relacionado com energia, etc…) em dispositivos móveis.
Aqui o mark critica. A aplicação nativa é mais vantajosa
Sobre o dart, ele também pode rodar na dartvm que é 28% mais rápida que o v8. :shock:
E é verdade, tenho estudado dart nas horas vagas e é uma grande realidade já.
Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.[/quote]
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?[/quote]
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat?
[quote=matheuslmota]
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?[/quote]
Você leu o tópico que esta respondendo?
Os usuários não estavam debandando por problemas na infraestrutura do Facebook, e sim porque a interface das apps não eram intuitivas.
[quote=fredferrao][quote=matheuslmota][quote=JoseIgnacio][quote=matheuslmota]
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura. http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/[/quote]
Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.[/quote]
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?[/quote]
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat? :P[/quote]
É isso aí. Eu postei logo atrás que era sobre a plataforma android mas ninguém deu importância.
Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.
Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.
[quote=JoseIgnacio]Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.
Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.[/quote]
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.
[quote=fredferrao][quote=matheuslmota][quote=JoseIgnacio][quote=matheuslmota]
Obviamente que não. Mas o consumo de CPU e de memória caiu 50% quando eles adotaram a estratégia. Isso impacta em menos gastos com infra-estrutura. http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php–move-fast/[/quote]
Se não me engano a maioria dos usuários acessam o facebook dos pads da vida, onde CPU e memória nem são tão limitados assim.
O problema não é infraestrutura do Facebook, e sim a debandada dos usuários.[/quote]
Acho que não fui claro. O facebook é escrito em PHP e escalar uma aplicação PHP para acesso a 1 bilhão de usuários requer uma infraestrutura gigante, enquanto que a mesma aplicação escrita em C++ (na verdade convertida para C++ com o uso da ferramenta que eu citei) tem um consumo de CPU e Memória 50% menor. Você leu o artigo que eu passei?[/quote]
Vem cá, voces estão falando de abacaxis e melancias.
A estória era sobre mobiles, e quando o facebook entrou na conversa era exatamente sobre o app android dele, que era um lixo, feito com webview, que nada mais é q um browser embutido no app. Ai misturaram com a parte server dele?? E um fala de devices e outro de PHP? Wat? :P[/quote]
É, mistuturei as coisas. Mas acima no tópico falaram de aplicação híbridas e de alguma forma eu associei com um sistema rodando em várias linguagens. Viajei total. Desculpem desviar o assunto.
[quote=juliocbq][quote=JoseIgnacio]Na verdade, não é sobre a plataforma android, ou mesmo iOS especificamente, e sim a tentativa fracassada do Facebook de usar HTML5 como uma plataforma de apps.
Minha resposta ao Sergio foi porque ele havia sugerido fazer exatamente isso.[/quote]
Entendi, pensei que era sobre o texto do mark falando que comparado com a alternativa nativa, a web não é tão boa.[/quote]
Mas não ha que tomar a parte pelo todo. O fracasso do facebook foi do facebook, não da tecnologia em geral nem da ideia base. E como alguém já disse o fracaso foi relacionado à UX e não à tecnologia.
Tudo é uma questão de economia. Se for mais economico ir para o nativo, força. Mas na maior parte das situações onde vc quer ambrangencia e não profundidade ( ou seja, quer ter presença e não performance) a solução hibrida é melhor.
E coisas como o PhoneGap dão acesso às mesmas API que o nativo (GPS, sensores, etc;…) porque são aplicações nativas no final de contas. São “adapters”. Então a performance vai ser a mesma que uma aplicação nativa. O que difere é que no HTML o cara poderá ter mais dificuldade de fazer uma app com a cara nativa. Por outro lado é mais facil criar uma com uma cara diferente. Tem uma palestra sobre isto que achei interessante com exemplo de aplicações relativamente avançadas com html5 rodando no PhoneGap.
