https://media.blubrry.com/hipsterstech/content.blubrry.com/hipsterstech/hipsters_038_javascript.mp3Podcast: Play in new window | Download | Embed RSS | More Compartilhar Assinar O Reino encantado do JavaScript – Hipsters #38 04/04/2017 / front-end Podcast programação web / 89 Comentários JavaScript tomou a comunidade de desenvolvedores como uma tempestade! Saiu de patinho feio para a queridinha hipster. Como isso aconteceu? O que mudou? Onde e como ele é utilizado atualmente? Bem, a resposta é simples: em todo lugar, de todas as maneiras. Vamos falar de alguns frameworks, alguns usos e reclamar bastante. Sim, esquecemos de falar do ember e de outros. Participantes: Paulo Silveira, host do Hipsters Mauricio Balboa Linhares, o cohost da treta Jaydson Gomes, o cara da BrazilJS! Flávio Almeida, o cangaceiro do JavaScript na Alura e na caelum Sérgio Lopes, nosso guru front-end Links bacanas: Porque começar a programar com JavaScript Overview de todas as mudanças do ES6 (em inglês) Episódio #16 sobre Single Page Applications Portal BrazilJS e evento BrazilJS Conf Todos os cursos de front-end da Alura, onde tem muita coisa de JavaScript! Produção e conteúdo: Alura Cursos online de Tecnologia – https://www.alura.com.br === Caelum Ensino e Inovação Edição e sonorização: Radiofobia Podcast e Multimídia Relacionado
William Oliveira - 1 Fala, galera! Também fiz um post, em PT-BR, com um geral sobre ES6: https://medium.com/@woliveiras/sim-outro-post-sobre-ecmascript-2015-ou-es6-6d50a7f33bd4 Responder
Flávio Almeida - 0 Ah, não exagera querido co-host! Eu sei um “pouquinho” de Rust. Ela não compete com as outras. É treta!!!!!! 🙂 Responder
Welton Vaz de Souza - 0 @flaviohalmeida Obrigado Professor! do hipsters e vc foi e é a pessoa que me ensinou Javascript que gostei transformado aprendizado em diversão! Obrigado @paulo_caelum e equipe da Alura. Responder
Flávio Almeida - 0 Fala cangaceiro! No fundo, eu que tenho que agradecer por você ter sido meu aluno. Aliás, não existe professor sem aluno. Fico muito contente em saber que pude aliar o bom humor à aprendizagem de uma tecnologia e tornar esse sertão da aprendizagem menos chato. Sucesso e bom estudo meu aluno! Responder
Ricardo Lima - 0 Só acho que faltou chamar o Suissa para participar o podcast.. para ele JS é algo divino. kkkk Responder
Sérgio Lopes - 0 Ia ter que colocar muito Piiii na edição hahaha. Brincadeiras a parte, precisava mesmo, quem sabe numa proxima 🙂 Responder
Leo Cavalcante - 0 Query selector foi inspiração da jQuery? Não foi da especificação do CSS que a jQuery implementou no JS? Responder
Sérgio Lopes - 0 A ideia de usar seletores CSS pra selecionar elementos no JS foi do John Resig em 2005: http://ejohn.org/blog/selectors-in-javascript/ Claro, ja existiam os seletores no CSS, mas na epoca o JS nem tocava nisso. Ai veio o jQuery e a ideia foi padronizada no querySelector. O primeiro rascunho da spec (na epoca document.matchAll() ) saiu em 2006: https://www.w3.org/TR/2006/WD-selectors-api-20060525/ Responder
Alexandre Costa - 0 galera tive dificuldade no node.js principalmente na organização da sua estrutura dos arquivos então pergunto o que devo saber antes de sair do javascript front para o back tipo saber mvc, O.O e etc. Responder
Maurício Linhares - 0 Olha, é bom ter uma idéia de MVC mas se você pegar um framework como express ele já deve ajudar a abstrair um bocado desse entendimento inicial. Meteor.js é uma boa pra começar também. Responder
Pedrinho Aoki - 0 Gostei bastante do podcast e concordo com o Sérgio em relação ao Node. Muitos acham que é bala de prata para o back-end. Mas é necessário entender melhor os requisitos decada projeto, são diversas variáveis que podem influenciar na decisão de usar Node ou não. Faltou falar de typescript ( Em quais situacoes devo migrar meu codigo para TypeScript? Qual area que o Typescript veio atender que o JS nao atende?) Responder
Mateus Queiroz Correia - 0 Também senti falta do Typescript, mas como a turma da Alura é tão inteligente, deve estar preparando um episódio sobre o tema, uma vez que ele é mais amplo. Quando forem falar, talvez vale a pena comentar que a própria google adotou o typescript para o Angular 2^ Responder
Patrícia Lima - 0 Melhor episódio! Vocês poderiam fazer mais episódios assim, mostrando o contexto da linguagem, desde que ela foi criada até o Boom dela. Ajuda a entender algumas coisas. Parabéns pelo podcast e pelo episódio! Responder
Leandro Severino - 0 Parabéns pelo EXCELENTE podcast. Com certeza está nos favoritos do que eu já assiti. Visite também a nossas página no Facebook: – https://www.facebook.com/maxigenios Visite também o nosso grupo no Facebook: – https://www.facebook.com/groups/maxigenios E também o nosso blog: – http://profissionaldetecnologia.blogspot.com.br Ob: Este material já está publicado lá no grupo 😉 Responder
Vinícius Santos Albuquerque - 0 Muito bom o podcast Sugestão: Coloquem configuração de velocidade de execução no player. Eu sempre tenho que baixar para rodar em 2x no computador. Responder
Sérgio Lopes - 0 Vinicius, tem uma gambiarra que eu faço: abre o console do chrome e cola: `document.querySelector(‘audio’).playbackRate = 2` Responder
Diogo Machado - 0 Muito bom esse podcast! Já vou seguir os participantes no Twitter, me amarro em Javascript. Responder
trumae - 0 Nao dah pra fugir do JS no Browser. No backend eu tenho problemas com JS. Mas tambem tenho problemas com Ruby e Python :). Esse tipo de linguagem eh otimo pra prototipos e prototipos eternos. Mas se o sistema fica de porte medio, vira um inferno. A desculpa eh que se escreve muito menos do que em linguagens com tipagem mais forte como C++ ou Java, mas parecem que nao contam a montanha de codigo de testes a mais que se tem que escrever em JS ou Python. Em linguagens menos “dinamicas” precisamos escrever muito menos testes. Mas sempre podemos escrever rapidamente uma goiaba sem escrever testes, neh? 🙂 Responder
Flávio Almeida - 0 ” Em linguagens menos “dinamicas” precisamos escrever muito menos testes.”. Se você se referiu a linguagem estaticamente tipadas, há uma surpresa aqui. Estatic typing não blinda seu runtime 🙂 Aliás, o que acontece é o posto! Pesquisa realizada pelo titio Elliot demonstrou que projetos feitos em Java ou C# possuem muito mais issues abertas do que projetos com linguagens dinâmicas. Qual o motivo? A cobertura de testes. A cobertura de testes não muda para uma linguagem dinâmica ou uma estaticamente tipada. Teste unitário continua sendo teste unitário, teste de integração, continua sendo de integração. Responder
Flávio Almeida - 0 “Em linguagens menos “dinamicas” precisamos escrever muito menos testes.”. Linguagens menos dinâmicas, você diz as com tipagens estática? No número de testes não tem relação com essa ou aquela linguagem, porque se você faz teste unitário, esta testando a menor unidade testável de seu sistema, se você faz teste de interação, esta testando algo maior. Aliás, pesquisa recente do Eric Eliot ao levantar projetos nas mais diversas linguagem apontou que linguagem estáticas como java e C# são as que possuem maiores issues abertas, um número menor do que projetos feitos dom JavaScript. Ou seja, a tipagem estática não protege o seu runtime, ou seja, só um teste pode demonstrar se o seu código faz corretamente o que ele deveria fazer. Então, na minha experiência e pegando carona na pesquisa do Eliot, não faz muito sentido dizer que linguagens “menos dinâmicas” escrevem menos testes. É treta!!!!!!!!! 🙂 Responder
Flávio Almeida - 0 Ah, e por ser linguagens dinâmicas, você não precisa usar mocks ou outros artefatos bizarros para dar uma volta no compilador e poder testar seu código. Sendo assim, o burdem para testar linguagem “menos dinâmicas” (eu entendi que você quis dizer estáticas) é bem maior. Responder
trumae - 0 Flavio, eu nao escrevi que TDD nao eh necessario. Soh que parte do que se escreve em linguagens dinamicas jah eh feito pelo compilador das linguagens com tipagem forte. E isso eh pouco discutido. Procurei esse Elliot, li um artigo dela ha respeito. Li o do Uncle Bob que originou tudo. Concordo com o Uncle Bob. TDD eh necessario. E bons programadores devem usa-lo. Meu ponto eh que linguagens estaticas jah provam varios “teoremas” sobre seu codigo, e isso torna possivel escrever menos testes. Muitos desses teoremas sao bem mais forte que testes baseados em casos. Obvio que nao eh prova de corretude, ate pq o compilador nem saberia que teoremas provar pra isso. Alem da dificuldade de provar a grande maioria das proposicoes interessantes. O TDD inventado pelo pessoal do SmallTalk, de acordo com o Bob, e o melhor que nos temos. Donald Knuth, ao escrever o Tex, fez algo muito parecido e estava usando uma linguagem fortemente tipada. Responder
Flávio Almeida - 0 Tem uma coisa que não disse, que acho que é o lado que você estava se referindo. Se programamos com uma linguagem dinâmica e queremos garantir que o tipo recebido é aquele que esperamos, temos que realizar uma série de testes (aqui sai dos testes unitários…ou escopo). Nesse caso, se o programador for por esse lado, ele escreve sim, um monte de código que não existiria se a linguagem fosse estaticamente tipada. Responder
trumae - 0 Acho dificil entender algumas atitudes: na hora de automatizar tarefas no desenvolvimento, o pessoal de Ruby, Python e JS manda muito bem. Mas usar tipagem? Nao, isso eh o demonio! Responder
Eduardo Henrique - 0 Poderiam ter mencionado o Electron.js que ta começando a dominar o mundo desktop também. Podcast 10/10 Responder
Ulisses de Castro - 0 Ontem, estava estudando sobre ele, muito interessante, fiquei mais animado porque consegui integrar um projeto angular js nele. Responder
Flávio Almeida - 0 Tem uma surpresa de Electron… vindo por ai. Não é minha, mas estou acompanhando. Aguardem! Responder
Maurício Linhares - 0 Hahah, falta de react e react native, angular, ember, electron, tanta coisa boa 😀 Responder
Flávio Almeida - 0 Algum passarinho me contou que terá alguma coisa de Electron numa das melhores plataformas de ensino online. Vamos aguardar! Responder
Gustavo Edny - 0 Que coisa linda! Tava já pedindo pra fazer um podcast sobre JS. Muito bom! Responder
Edy Silva - 0 Muito show! Estou viciado nos podcasts. E sou fã do Python estou esperando ansioso Responder
Samuel Rocha - 0 Excelente cast pessoal, parabéns, pena que a treta não foi maior 🙂 Não teria como falar sobre todo o universo Javascript em uma hora, são tantos frameworks que eu nem sei contar hehehe. Jaydson e o Felipe mandam muito bem no BrazilJs, a conferência é incrível, só estou esperando a desse ano / Responder
Flávio Almeida - 0 Nem podia ter muita treta com o cangaceiro aqui! Ninguém iria me encarar 🙂 Responder
Jose Paulo - 0 Galera sou dev backend, e já tentei me aventurar no front(não deu certo rsrsrs). Qual a real relevância do nodejs, vale a pena começar um projeto com node hoje, ou uma linguagem(sei que nodejs não é uma linguagem) com mais tempo, ou mais madura, como php ou python. Valeu Responder
Flávio Almeida - 0 Tem que perguntar para a Microsoft, Paypal, Wallmart, Twitter e outras grandes empresas corporativas que usam Node.js em produção 🙂 Sem puxar a sardinha pro lado do JavaScript, talvez seja interessante investir naquela que tem mais oferta de emprego perto de você. Há também o fator motivação. É balancear a necessidade do mercado e seu gosto. Só não esqueça que dominar JavaScript é mais de meio caminho para aprender a plataforma Node.js. Abraço João! Responder
Zava - 0 Tinha q dar um tapa na cara desse cara quando fala q prefere Java no back em vez de Node. (uma crianca morre na africa cada vez que vc nao usa node no back) Responder
Flávio Almeida - 0 Não era um bebê foca? Saindo do mundo da treta e vido mais para o mercado, o Java apesar de ser uma linguagem mais verbosa que o JavaScript e outras do mercado, conseguiu consolidar plataforma. Há zilhões de empresas que investiram em treinamento e infraestrutura em Java. O Node.js hoje frequenta ambientes corporativos, mas com o advento das Web APIS (micro serviços), no final das contas o dev faz sua API com a tecnologia que for melhor para aquele problema específico. Há espaço para todos.. feliz é aquele dev que sabe transitar em cada uma das tecnologias e aplicar aquela certeira para o problema. Aliás, qualidade de um bom cangaceiro desenvolvedor. Abraço Zava! Responder
Luiz Fernando Alves - 0 Eu fiquei confuso com o comentário: “Se fosse por performance todos escolheriam C, C++ ou Java”. A performance de NodeJS não seria superior por ele ser dirigido por evento em um single thread? Responder
Maurício Linhares - 0 Nope, C, C++ e Java continuam sendo mais rápidos, sendo single thread ou não. Tem várias soluções que usam event-loops nessas linguagens (e bem anteriores ao NodeJS, inclusive) como o Netty no Java. Responder
Clayton Passos - 0 Fim da guerra dos browsers? Quando isso acabou que eu não to sabendo? Tenho de lidar com IE, Edge, Firefox, Chrome, Neon no desktop, sem falar que a nova versão do Chrome (56 e 57) quebrou um monte de coisas que funcionavam, pra piorar, hoje tenho que lidar com o mobile que me impôe as mesmas variações em celulares, tablets, e smart TV, e no mobile ainda tem o navegador do Android que nem não é nenhum desses que comentei anteriormente. Ao meu ver a guerra dos browsers só piorou, nunca acabou. Mas tudo bem, no final tenho programado usando Java, Vue e Angular 😀 Responder
Rafael Antonio da Silva - 0 Alura deixa a desejar nos cursos!! Sugeri há mais de 3 meses o curso de AWS e nunca foi feito! (sendo mais votado na pesquisa) Responder
Flávio Almeida - 0 Olá! nesses 2 meses, estamos trabalhando no curso de AWS focado no EC2 e outro focado no S3. E estamos planejando mais. Responder
Rafael Antonio da Silva - 0 Obrigado pela resposta! Sou aluno e estou super esperando conteúdos sobre AWS. Fico no aguarde destes citados e dos próximos, abraço! Responder
Flávio Henrique Almeida - 0 Saiu hoje https://cursos.alura.com.br/course/introducao-ao-cloud-do-ec2-no-aws Responder
Flávio Henrique Almeida - 0 Boa notícia! https://cursos.alura.com.br/course/introducao-ao-cloud-do-ec2-no-aws Sucesso e bom estudo meu aluno! Responder
Maurício - 0 É um sonho distante, mas seria maravilhoso ver um curso da Alura sobre IoT e Node.js Embedded (https://tessel.io/) Responder
Ronan - 0 Olá, poderia citar alguns exemplos de situações em que equipes que trabalham com outras linguagens back-end optaram por adotar Node para determinada solução? Em outras palavras: em quais situação que uma aplicação baseada em Java, Python, PHP precisou optar por Node? Responder
Pedro Scursel - 0 toda vez que o Flávio fala, me vem ele na cabeça no canto inferior esquerdo, com fundo de chromakey, que nem nas aulas da alura heheheheheh Responder
