Converter o site do Natal.Js para Next.js

[davidcostadev]

Acho que ficaria mais interessante para a comunidade se o proprio site do natal.js usasse um livraria mais robusta em javascript.

Atualmente está sendo usado apenas o html e css e javascript básico.

A motivação de usar o Next.js é porque precisa usar React para criar o site e com o next.js é possivel gerar páginas staticas(apenas html, css e javascript) que é suportado pelo github pages. Sem precisar alguma tarefa rodando para funcionar.

Links

• nextjs.org
• github.com/zeit/next.js

[Mazuh]

Faz sentido usarmos uma lib mais robusta. Só não entendi a motivação pra usar next.js. Com webpack, depois de fazer a página de qualquer modo, é só rodar o build que o bundle produzido é só html/js/css estático.

[davidcostadev]

Porque o Next.js é Algo mais focado nisto, sem precisa de muita configuração, com a possibilidade de focar apenas no desenvolvimento mesmo. Sendo assim fica mais produtivo.

O Next.js é um create-react-app só que para Server Side Render e Gerar Páginas státicas. Abistraindo essa parte do webpack para você.

O Next.js tem uma exelente documentação, tem até com desafios para você resolver dentro da documentação. Facilitando quem não sabe mexer, conseguir entender e contribuir.

[Mazuh]

Acho que entendi. Eu achei que o próprio npm build (do create-react-app, por exemplo) atendesse a todos os requisitos de "0 configuração" e "geração de documentos estáticos". Todos os artigos que vi explicam que o Next faz isso melhor, mas não entendi como. De qualquer forma, parece ser bem "battle proven", até o pessoal do GitHub usa. Como a ideia já tá bem direta, vou subir a label de proposta e esperar alguém mais se pronunciar.

[davidcostadev]

Outro argumento é que p Next.js já é mais preparado para SEO, ele consegue salvar o render final dos components, assim os Robots de buscam vão conseguir indexar melhor.

[jhonnymichel]

Sei lá, de início acho sem sentido. Qual o problema com simplesmente usar html css e js? Esses ome são mto viciado em lib. Isso é só um site estático.

[victor-torres]

Atualmente está sendo usado apenas o html e css e javascript básico.

Ótimo! Espero que continue assim.

[lucascassiano]

So sugestao, entre Next e Parcel, acabo usando mais Parcel.. pela simplicidade e velocidade

[Mazuh]

@jhonnymichel não há nenhum problema, a primeira frase da issue diz explicitamente que é só um achismo de que seria mais interessante, não que resolveria algo.

Ao que eu pergunto (também a @victor-torres), qual seria o problema de ampliar a stack do site? Lembrando que não estamos em uma empresa, não há mal algum em perder tempo brincando com JS, fazer, refazer, reinventar etc. ^_^ Discorram um pouco melhor seus pontos.

[victor-torres]

@Mazuh

Não estamos numa empresa, mas estamos numa organização. Isso me faz pensar que um site estático mais simples, porém organizado, é mais fácil e barato de manter. Não é porque o trabalho é voluntário que não existem custos! Um código mais enxuto está mais aberto a receber contribuições do que um mais complexo.

Sobre a parte de experimentar, eu acho válido, porém tem que avaliar a situação. Eu acho mais proveitoso pra todo mundo se o site principal do NatalJS for simples de usar e manter e funcional no ponto de vista de usuário final. Tem o GitHub disponível pra gente inventar outros projetos mais complexos e experimentar com novidades :)

[]s

[victor-torres]

Complementando, não acho que seja um problema aumentar a stack do site, principalmente se a gente fosse agregar um gerador de sites estáticos, por exemplo. Só acho muito overkill colocar React ou algo do tipo numa página tão simples.

[victor-torres]

Temos que lembrar que o objetivo principal das pessoas visitarem o site do NatalJS é adquirir informações simples como uma tabela com datas e horários dos próximos eventos, links para falar com a staff ou entrar em grupos do Telegram, por exemplo. Isso é um problema que um site estático resolve muito bem e não faz muito sentido usar JavaScript pesa no frontend pra resolver isso.

[jhonnymichel]

"A motivação de usar o Next.js é porque precisa usar React para criar o site".

Nao precisa.

A argumentação tá fraca até então.

Por que você acha interessante usar uma "livraria" mais robusta? O que não temos em robustês atualmente? Qual a nossa necessidade?

Outra coisa, se precisarmos de um dom dinâmico, eu concordo que react é uma boa opção. Mas aí, a gente pode plugar o react só nessa parte do site e é isso. React é uma biblioteca. A gente nao precisa usar ele exclusivamente.

"ah, mas e o seo?"

Google indexa conteúdo dinâmico desde 2016.

https://medium.freecodecamp.org/seo-vs-react-is-it-neccessary-to-render-react-pages-in-the-backend-74ce5015c0c9?gi=a3279e78b93b

Sendo assim, next js tem 0 necessidade e usar React pra conteúdo estatico é desnecessário. Podemos usar React pra uma sessão específica do site se necessário no futuro e é isso.

[Mazuh]

Bom, ainda vejo como uma simplória proposta de experimentação, se não gerar pontos negativos a nenhum de nós, não faz sentido declinar. Parece-me que ele se predispõe a "assumir os custos", logo qualquer análise nesse caminho não faz sentido. E, de novo, a issue não se propõe a resolver problemas. Em tempo, gostei do comentário sobre experimentar em outros repositórios.

Enfim, serei mais direto: algum de nós -- a exceção de David -- tem algo a perder ou se prejudicar com a proposta? A comunidade se afeta negativamente de alguma forma? O site em si perde alguma feature/requirement de forma significativa?

---

Off topic.

Estou tentando estimular uma discussão mais nesse sentido porque não vejo motivo de nos fecharmos a propostas nos baseando somente em "se fosse eu, não faria". (Tenho certeza de que todos nós já sofremos de microgerenciamento na vida e isso não acontecerá aqui.)

Foquem no que eu questionei, por favor.

[Mazuh]

Respondendo à minha própria pergunta...

Vi que o site já usa o "JS pesado", tem uma lista já grandinha de dependências de desenvolvimento. Enxergo a adição do Next como potencial obstáculo à manutenibilidade do site. @davidcostadev, você teria algo a me responder sobre isso? No que isso iria alterar na hora de fazer deploy do site ou de um novato começar a mexer? Consegue mensurar esse impacto?

[jhonnymichel]

Eu não acho que estou usando o método "eu não faria". Eu sei que estou usando uma comunicação violenta aqui mas ignorando isso, minha argumentação se baseia em "por que diabos?". Pontos negativos são: pra fazer uma simples alteração nesse site o ser humano vai ter que se submeter a entender uma stack sem necessidade. A gente pode fazer esse tipo de coisa em projetos específicos pra isso

[Mazuh]

@jhonnymichel entendi, mas vamos focar só no "por que não". Ou seja, assumirmos uma postura de estarmos abertos a qualquer proposta a princípio, de forma que esse repositório Community seja uma "burocracia" só no sentido lato da palavra, não um obstáculo que alguém deva vencer para contribuir à comunidade.

Ficaremos no aguardo de @davidcostadev sobre nossos questionamentos.

[jhonnymichel]

Beleza. Gostei @marcell. Concordo.

[davidcostadev]

Vou listar alguns beneficios práticos, com base do meu ponto de vista e minha expericencia de porque usar Next.js.

• O site pode virar um case de sucesso de uso do next.js e react para a comunidade.
• É bem simples de configurar e produzir.
• Com o react podemos facilmente fazer componentes que exigam reatividade.
• Já tem uma forma muito simples de gerar site html statico e SEO amigável.
• Para quem é iniciante pode ser um lugar para mentoria das contribuição.
• Acho que poderiamos melhorar o site com algum conteudo dinâmico.

Respondendo perguntas

• "Por que você acha interessante usar uma "livraria" mais robusta?" O Next.js é um framework, que consegue resolver todos os pontos que envolve o desenvolvimento de páginas estáticas
• "O que não temos em robustês atualmente" Precisamos melhorar a forma de como o build está feito, e junto resolver outros problemas
• "Qual a nossa necessidade" Listei a cima
• "Vi que o site já usa o "JS pesado", tem uma lista já grandinha de dependências de desenvolvimento" O next.js consegue resolver isso com minificação e chunk, só não tenho certeza com relação ao sites estáticos (Mas, nenhuma tecnica consegue resolver se vc coloca 1 milhões de pacotes)
• "No que isso iria alterar na hora de fazer deploy do site ou de um novato começar a mexer" Com relação a isso continuaria o npm run build, só mudaria as coisas por baixo.
• "um novato começar a mexer" Acho que com relação a medo da curva de aprendizado, acho que é esse o proposito da comuidade puxar todo mundo para cima, e forçar a aprender.
• "Consegue mensurar esse impacto", * Não cada pessoa aprende de uma forma e de um tempo**

Não acho que isso pode prejudicar muito o escopo do repositório do website do natal.js.

Como o @Mazuh disse, é uma sugetão, de repente podemos fazer como disse o @victor-torres, usar em outro Projeto. Por mim OK se vocês acham desnecessário.

[jhonnymichel]

Meus argumentos para "por quê não"

Eu entendo que usar o Next.js nesse site é uma tentativa de resolver problemas de build, padronizar a maneira de desenvolver o site e já apresentar uma tecnologia consolidada para a comunidade. Todos esses pontos são excelentes, mas não acredito que usar Next.js para esse site é a melhor solução pra gerar o impacto que queremos gerar:

• É uma tecnologia muito específica e arbitrária para o site. quero dizer que os mesmos argumentos que @davidcostadev usou em favor do Next poderiam ser usados em favor de muitos outros frameworks/estratégia (praticamente qualquer outro), justamente por ser uma escolha genérica baseada mais em gosto pessoal.

• Usar tecnologias web padrões e plugar o site progressivamente quando a necessidade for surgindo é um caminho mais lógico e justificável. É como as coisas funcionam no mundo real e mostraríamos pra comunidade que é possível criar algo com as tecnologias de base, e usar bibliotecas e recursos mais específicos em conjunto com isso quando necessário, sem ser de maneira determinística. Ex.: React é uma biblioteca. não tem problema usar ele só pra uma seção do site. não precisa usar react router + react + redux em todo o site só porque vai ter uma seção dinâmica.

Referência para esse argumento: https://en.wikipedia.org/wiki/Progressive_enhancement

• A comunidade front-end sofre muito de tooling addiction. Pra mim, estamos passando a mensagem errada ao pegar um site simples e usar uma engine como next pra fazer ele. O consenso geral sobre a direção do desenvolvimento front-end é de que devemos usar a plataforma disponível nativamente pra desenvolver, e apenas adicionar ferramentas diferentes quando precisarmos delas. A Google lançou uma hashtag ano passado, que é a #UseThePlatform pra difundir essa mensagem. O pessoal que tá começando vai entender que Javascript, HTML e CSS estão lá, prontos pra serem usados sem a necessidade de nada a mais pra começar, ao invés de terem a percepção errônea de que adicionar várias camadas em cima do ambiente de desenvolvimento é o way to go.

Referências para o argumento sobre tooling addiction https://www.youtube.com/watch?v=hlYiWznhhzw&t=69s Referências para o argumento sobre a plataforma web #UseThePlatform https://www.youtube.com/watch?v=xzzQWc-IqZI

Resumindo: Essa sugestão de usar Next.js é, pra mim, um sintoma do problema que a comunidade web sofre hoje (tooling addiction, não entender a plataforma web) e nós como comunidade deveríamos adotar a prática contrária. Isso inclusive abre a oportunidade de outra discussão, sobre justamente qual vai ser nossa posição em relação à isso, pois apesar de tudo, o resto do pessoal pode simplesmente não concordar comigo e querer sim incentivar tooling e tratar a plataforma como algo não pronto para as necessidades atuais do front-end.

Qual direção vamos tomar?

[victor-torres]

@Mazuh, sobre microgerenciamento, infelizmente eu já passei muito por isso e definitivamente não é o que está acontecendo aqui. Na verdade o que tá acontecendo é algo muito proveitoso pra comunidade, pois trata-se de uma discussão saudável e que na pior das hipóteses só vai fortalecer o ponto de vista de todos que participaram democraticamente dela. Meu objetivo não é proibir o uso de react, apenas discorrer sobre a real necessidade de uso dele aqui. Aliás, recomendo este link sobre isso: https://css-tricks.com/project-need-react/

O que nos leva à sua colocação de que o que deveria estar sendo discutido não é a necessidade ou não, mas sim a oportunidade de utilizar tecnologias novas para treinar e praticar a arte de programar JavaScript. Sobre isso, eu reconheço que é uma ideia válida. Apenas eu não me sinto muito confortável em aplicá-la no repositório do site principal da organização. Pra mim deveria ser um site simples, estático e com o mínimo de JavaScript e utilizado apenas para melhoria progressiva.

A comunidade ganharia muito podendo participar de um projeto que é de fato utilizado no mundo real, mas eu considero igualmente contra-produtivo forçar a utilização de uma tecnologia num projeto que não precisa dela apenas para "aprender". Simplesmente porque o público-alvo de ações como essa não é maduro o suficiente para entender que a tecnologia escolhida está sendo utilizada apenas com finalidade de aprendizado. Isso seria, na minha opinião, contribuir com o conceito errado de utilizar bibliotecas JavaScript para resolver praticamente todo tipo de problema. Importar o jQuery para selecionar um elemento no DOM por seu ID. Ou até muito pior do que isso: criar problemas só para ter que resolvê-los de uma forma bacana.

Aliás, acho que isso é o que mais fundamenta minha opinião pessoal a respeito desta thread: às vezes utilizar uma ferramenta num contexto incorreto pode ter menos prós do que contras na educação (aqui vale a pena ressaltar que o que é incorreto para mim pode não ser pra vocês nesse exato momento). As pessoas aprendem muito pelo exemplo e pela analogia e a nossa área é de certa forma carente de bons exemplos. Isso pode ser útil para demonstrar conceitos a profissionais mais experientes ou até mesmo mostrar que certas tecnologias não são adequadas em determinados cenários, mas rebatendo a proposta de utilizar isso como sandbox pra usuários novatos, acho complicado explicar isso pra quem está começando quando o exemplo que estamos dando é exatamente o inverso.

Nós temos plena capacidade de criar sub-projetos da NatalJS com ideias válidas e com uso justificado dessas tecnologias para incentivar a contribuição da comunidade.

tl; dr;

• microgerenciamento não está acontecendo aqui
• a discussão democrática é benéfica para todos da comunidade
• acho que o site deveria ser html e css simples com o mínimo de javascript
• não devemos criar problemas apenas para poder corrigí-los
• a comunidade pode criar projetos mais adequados para a comunidade poder contribuir

[victor-torres]

Situação hipotética: existe uma comunidade chamda NatalPY, sobre Python. O que vocês diriam se sugerissem utilizar Django pra fazer a página simples da comunidade aqui no GitHub? Eu acharia muito overkill, iria preferir um site mais simples. Deixa o Django pra projetos mais complexos.

Mas ninguém iria morrer se resolvessem usar Django (ou Next, React etc.). Só acho desnecessário e acrescentaria uma maior dificuldade em manter e contribuir com o site.

[]s

[Mazuh]

@victor-torres Confesso que parei de ler em "apenas eu não me sinto confortável", porque não é tu que vai fazer, né. hehe Então considero que qualquer coisa depois disso é microgerenciamento, sim. Sobre o tldr: concordo que a discussão seja boa, mas bloquear experimentações por causa de discussões teoréticas e subjetivas é que de fato é muito contra produtivo (se eu fosse David, por exemplo, já teria aberto o PR e essa discussão estaria rolando lá); também continuo achando sem sentido falar sobre problemas porque a comunidade não será movida a tickets nem terá sua produtividade mensurada por resolução de problemas desse tipo.

Mas gostei do argumento de @jhonnymichel sobre tooling adiction, parece bem objetivo e extremamente tocante à comunidade. E estou muito mais inclinado a recusar essa proposta e considerar a abordagem que todos parecem concordar: outro projeto seria mais adequado.

O que você acha, @davidcostadev?

[victor-torres]

@Mazuh, não sei quais são as suas definições de microgerência, mas definitivamente isso não se encaixa aqui. Até porque não tem ninguém acima de ninguém até onde eu saiba. É uma proposta, o ticket até leva essa tag, por que não compartilhar a opinião? Fora que em nenhum momento eu estou interferindo no trabalho de ninguém, estou dando a minha opinião porque isso aqui é aberto pra isso.

Aliás, lamento que você tenha parado de ler no ponto em que apenas disse que essa era apenas minha opinião. O que eu quis dizer com isso é que justamente não é por causa dela que vocês vão deixar de fazer ou não. Estou apenas contribuindo um pouco com o meu ponto de vista baseado na minha própria experiência. Não é isso que todos fazem aqui?

Realmente o @davidcostadev poderia ter simplesmente aberto o pull request. A gente poderia gostar, ou criticar, mas poderia ser melhor do que o que existe hoje... Mas propostas servem para evitar esforço desnecessário. Muitos projetos abertos funcionam dessa maneira, essas discussões são importantes para garantir que tá todo mundo na mesma página e eventualmente a gente pode chegar num direcionamento melhor.

Uma vez a comunidade decidindo os rumos do projeto, acho que cada um é livre pra implementar as coisas da forma como bem entender, desde que dentro dos padrões mínimos de aceitação como qualidade de código etc., sem gerenciamento ou microgerenciamento, como você insiste em trazer para esta thread.

[Mazuh]

Sigo dizendo, vamos nos atentar somente aos pontos negativos e a críticas objetivas, como Jhonny fez, com o objetivo de ver se essa proposta é declinada ou não -- qualquer pointless comment pode ser feito, mas não considerado de fato. Existem outros canais para comentar sem objetividade, como no Telegram (sequer argumentei lá).

Não tem condições de uma comunidade ser aberta a propostas se toda ideia de experimentação vier com comentários de "se fosse eu, não faria". É uma conversa sem rumo que só bloqueia a colaboração a troco de velhos conversando.

Enfim, tô no aguardo do que David acha dessa possível solução.

[Mazuh]

~Disclaimer.~ Eu concordo com seus pontos, @victor-torres. Meu site pessoal, por exemplo, sequer tem package.json e eu não tem quem faça eu mudar de ideia sobre isso. Mas reconheço que esses pontos não deveriam ser levados em consideração pra bloquear a contribuição de ninguém na Natal JS, a menos que essa contribuição tenha impactos negativos na comunidade. Eu sequer havia manifestado esse ponto de vista aqui (e se eu manifestasse, teria sido no Telegram só por motivos de pointless discussion). A argumentação deve ser levada nesse caminho: presunção à aceitação. E quando eu quiser que algo seja implementado do meu jeito, eu quem vou lá implementar.

[victor-torres]

Legal, @Mazuh. Eu entendo pra onde você tá querendo levar a discussão e acho legal isso que você tá fazendo. Eu falei sobre os impactos negativos nos meus comentários e eles batem muito com os que o @jhonnymichel citou. Inclusive coloquei um link que explica um pouco isso (https://css-tricks.com/project-need-react/). Resumindo: não seria um bom exemplo de caso de uso pra React e poderia confundir os novatos, contribuindo pra o mal costume de usar biblioteca JS pra tudo.

[davidcostadev]

Então, muito obrigado por todos que comentaram aqui e levantaram sua opnição sobre o que é melhor para comunindade independe do que é bom para o individuo.

Concordo com o ponto de @jhonnymichel que pode ser um tooling addiction. E que podemos usa-lo em outro momento oportuno. (Apesar de pessoalmente não achar isso um problema, se isso pode ser algo que força-nos a aprender algo novo).

[Mazuh]

Beleza, então. Parece que nossas discussões chegaram a um consenso. Acho ótimo. :D Estou ansioso para em breve abrir issues sugerindo novos projetos, e quem for tocá-los que implementa da forma que achar mais conveniente, seja por Next, Parcel, create-react-app ou vanilla.

Mas, só pra sumarizar, concordamos em não aceitar essa proposta diretamente ligada ao nosso site principal, meramente por questões de postura diante do tooling addiction e do que o reconhecimento disso como representatividade problemática. Tô fechando a issue mas qualquer discussão pode prosseguir.