E possivel atuar no mercado de trabalho com js puro?

[fernandoRj]

fala galera boa noite, e o seguinte, atualmente me vejo bem a vontade com js, na parte de criação de interface e manipulaçao do dom, sei criar algumas coisas em javascript, estou trabalhando nos meus projetos com o ecs5 ainda, eu continuo com purejs ou ja parto para aprendo reactjs? tendo em vista que ate agora ja fechei 2 projetos free lancer, um foi criaçao de uma dashboard com firebase, e um ecommerce, ambos fiz com ecs5 e firebase

[Roger-Melo]

Qual motivo você teria para não aprender uma ferramenta que pode alavancar sua produtividade e te fazendo focar no que realmente é importante em aplicações JS, como o React?

Indico o React Ninja, do Fernando Daciuk (várias features de ES6 inclusas no curso): https://queroser.ninja/promocoes

Tem o de JS Puro que é excelente também, caso queira se aprofundar ainda mais na linguagem antes de partir para alguma lib ou framework.

Outra: não há mais porquê utilizar ES5, babel tá aí pra isso. Se você já tem uma boa base na linguagem mas ainda escreve ES5, se atualize =)

[salatielsql]

É bem importante o conhecimento do JS puro. Muitos já começam em um framework aí perdem os conhecimentos da base do JS. Eu particularmente fiz isso que você fez, fiz vários projetos com JS puro e agora estou a um tempo usando React e ES6 pois realmente te ajuda a criar projetos com arquiteturas melhores e mais fáceis de dar manutenção no futuro.

Dale React! haha

[alexgwolff]

Fala dev,
Eu sou super fã de usar nativo mas são cenarios e cenarios.
Minha stack é react e nativo com web components.
Como decido o que usar?
Bem, react é sempre a primeira opção devido a produtividade e a facilidade de passar o projeto pra outro dev. No caso de nativo só vou pra essa abordagem caso o produto tenha design system e isso irá ser aproveitado em outras aplicações que podem ser em frameworks diferentes ou não.

[juanpinheiro]

Fala @fernandoRj,

Eu estive em uma palestra do Venkat e ele deu um exemplo muito bom sobre esse assunto. Durante a palestra ele falou sobre a relação entre o nosso transporte com a manipulação do DOM.

JavaScript Puro (antigamente) - Carro com câmbio manual - É difícil, além do caminho, você precisa ficar se preocupando com a troca de marcha e com a embreagem! Mas sempre tem um bonitão que fala que prefere assim.
JQuery - Carro com câmbio automático - Você ainda precisa se preocupar com o caminho, e ainda assim, dirigir longas distâncias é um saco.
React - Uber - Você não precisa dirigir, e se você não colocou o endereço errado, é só ficar tranquilo que você vai chegar lá.
??? - Teletransporte - Falamos sobre isso no futuro!

Manipular o DOM é um saco, frameworks e libs facilitam sua vida e te garantem produtividade. Eles só são populares pois são úteis.

Uma coisa que gosto de ter sempre em mente é que é importante saber a base e não se limitar! A cada dia que passa nasce um novo framework e uma nova lib para JavaScript, não se prenda a nenhum deles, aprenda vários e divirta-se, todos tem seus pros e cons! 😄

[ninetails]

Minha opinião atualmente e resposta filosófica da thread:

Saber é diferente de trabalhar com.

Gosto da analogia acima citada pelo @juanpinheiro. Somos evolucionistas, não seria lógico fazer um site hj em dia em Assembly ^{(claro, estou exacerbando ao extremo)}. Ferramentas evoluem, pessoas evoluem, tecnologias evoluem.

Claro que existe o "nem sempre para melhor", mas mesmo esta sentença é relativa. Existem muitas ferramentas agilizam o trabalho com o custo de ter um boilerplate e código não usado enormes, sujando código e até mesmo semântica tanto do código quanto do produto. Porém surgiram com o propósito de agilizar o desenvolvimento.

Mesmo na questão de JS em si é difícil falar sobre usar ele puro. A própria especificação evoluiu. Hoje a mais adotada é a ES6, que continua em plena evolução. Também é possível dar um passo a mais e usar ferramentas que transpilam seu código para o ambiente do produto final, como no caso do Babel, que vc pode transpilar código escrito em ES6+ para ES5... ou mesmo ES6 pra pegar navegadores mais atuais, e codar com funcionalidades que ainda estão em fase de proposta pela TC39 sem ter atingido a maturidade do stage 4.

Além disso temos a felicidade de ter diversos repositórios públicos e open source com inúmeros pacotes onde para as tarefas mais usuais, não precisando se importar se esse código foi bem testado, se há bugs etc pois a comunidade faz isso por ti (e claro que incito aqui o retorno, vc fazer pela comunidade).

E mesmo o JS em si tem tanta coisa em volta. Outros transpiladores inclusive de outras linguagens para suprir algumas deficiências do JS (como tipagem usando Typescript), compiladores... Exportar para mobile, IoT, servidores usando Node, TV, WebAssembly...

Claro, é muita coisa pra se ver e óbvio que não dá pra saber tudo. Óbvio que é necessário um direcionamento. Saber e entender JS é, claro, imprescindível pois não dá pra desenvolver bem em nenhum dos casos acima se não souber JavaScript bem, mas pense também que tempo é o único recurso nosso que é imensurável.

Digo isso por experiências passadas, duas coisas: não reinvente a roda e todo mundo precisa de dinheiro pra viver no mundo atual em que vivemos (digo como fato, não espero discussões históricopolíticas aqui). Dado isso, creio que é um bom ponto vc tentar aprender sobre ferramentas que agilizem seu desenvolvimento, aumentando a qualidade do produto que vc faz e trazendo uma melhor mantenabilidade, focando no que vc quer desenvolver e não em coisas triviais pois o trivial outros já tiveram esse problema e já fizeram alguma lib/framework para tentar mitigar estes problemas.

[simaodeveloper]

Discordo do @ninetails em relação a não reinventar a roda.

No dia a dia de trabalho reinventar a roda é realmente ruim, você pode estar trocando horas produtivas resolvendo um problema real que entrega valor para passar algum tempo entendendo como tal solução funciona e isso é ruim e concordo com o @ninetails.

Porém, acredito e reforço que crie Pet Projects (Projetos para aprender techs, patterns...) para entender como essas coisas funcionam, o dia a dia de trabalho fluirá melhor, aconteceu um caso comigo:

Criamos um serviço que realizava requisições via JSONP, porém toda chamada compartilhava o mesmo serviço, apenas trocávamos a URL conforme o contexto, só que acontecia um erro de sincronização que não conseguíamos encontrar, utilizamos o recurso do jQuery para criar esse serviço, onde passamos o nome do callback e a função.

Foi ai graças a reinventar a roda em meus pet projects com javascript puro que lembrei que literalmente ele configura essa função diretamente no escopo global do browser (window) e todas as chamadas que eu fazia utilizavam a mesma função, isso estava dando um problema de interceptação dos dados.

A solução foi passar um parâmetro para criar um nome para o callback para diferentes contextos.

Bom, fica aqui meus dois centavos, quanto mais tu reforça a base, mas fácil fica de entender como essas libs/frameworks funcionam, e sim estude também o que entrega valor.

Obs.: Acho que o maior problema hoje em dia é a ansiedade de aprender tudo ao mesmo tempo o quanto antes, minha dica é estude a base, crie projetos da sua mente, e utilize esse mesmo padrão para outras tecnologias que queira aprender e faça no seu tempo, não se compare com outros devs ;D

[juanpinheiro]

@ninetails @simaodeveloper acho que a gente pegou pesado com na resposta filosófica e esquecemos de responder com sinceridade a pergunta inicial, é possível atuar no mercado de trabalho com JavaScript puro?

Na minha opinião, dá pra trabalhar sim, entretanto você pode facilmente ganhar mais dinheiro sabendo React ou Angular, se no seu caso você pretende atuar no mercado como Software Engineer em uma empresa.

E vocês, o que acham?

[kvnol]

Dá pra trabalhar, mas a produtividade será melhor se usar um framework. Vanilla é verboso, frameworks ajudam exatamente nisso. Mas saber Vanilla, na minha opinião, é essencial. Cola nos cursos do @fdaciuk que é sucesso!

[simaodeveloper]

Sim, da para trabalhar com javascript puro, mas normalmente você atuará em legados ou pequenos projetos, que caso eles escalarem, provavelmente precisarão de frameworks para focar na entrega de valor e consequentemente você obterá um salário melhor. praticamente um complemento do que o @juanpinheiro e o @kvnol falaram.

[ninetails]

To junto com o @simaodeveloper

Quando o assunto é mercado e contratação (estritamente falando), falar javascript vanilla pra mim soa muito mais depreciativo (no sentido de pedir menos, básico, não pedir que o candidato saiba de mais coisas) que saber muito bem js vanilla em si.

Mesmo pq, vendo da visão do contratador, é difícil pensar em algo do tipo contratar um cara para não fazer um produto de mercado e focar tão baixo nível (apesar de js vanilla não ser tão baixo nível rs), e mesmo assim ainda acho que quem tem mais conhecimento seria um diferencial para não preferir o que sabe só vanilla.

Salvo exceções:

• vagas junior, trainee, estagiário etc que tá lá pra aprender
• IoT ou outras plataformas que qualquer lib adicional sobrecarregaria o desempenho da aplicação ou módulos personalizados "pequenos"

Por outro lado, se for considerar Node.js baunilha, talvez a carga de frameworks seja menor. Mas frontend vanilla não vejo como escalável para grandes aplicações sem uma boa arquitetura, muitas vezes gastando recursos e reinventando a roda.