
Existem sempre aspetos para otimizar num website, e, também, para atualizar já que o ecossistema de Javascript não dá sinais de abrandamento, aparecem novas _frameworks_ e as já existentes recebem updates praticamente todos os anos. Bem, sou um _developer_ que gosta de estar sempre a par da novidade e desenvolver com as ferramentas mais recentes, o único problema é o montante de tempo que isso implica, principalmente se for migrar projetos antigos. Contudo, há vezes que vale mesmo a pena migrar e atualizar um projeto do passado e é precisamente isso o que este post aborda, consistindo de um conjunto de divagações, que achei pertinente partilhar, de todo este processo de atualização/migração/otimização do meu website pessoal e que contém o meu portfólio. Bem, o principal motivo para considerar este processo de atualização válido e recompensador foi ter utilizado a _framework_ [Gatsby](https://www.gatsbyjs.com/) para o desenvolvimento do website já que o Gatsby me deu bastantes problemas no _deploy_ e no desenvolvimento continuo do website (estas ocorrências já foram há algum tempo atrás, atualmente já podem ter sido resolvidas). Estes inconvenientes mais a vontade de experimentar as tecnologias mais recentes levaram-me a entrar nesta aventura, claro, tudo isto com o intuitivo de melhorar o website, mas, também, aproveitar sempre para ir aprendendo coisas novas.

![Camões com uma epopeia de memes de refactoring {caption: Camões e as suas epopeias de migração/atualização/refactoring de projetos passados}](my-website-v2_camoes-aventuras-refactoring.png 'Camões com uma epopeia de memes de refactoring')

Relativamente à mudança da _framework_, assentei no [Next.js](https://nextjs.org/), pareceu-me ser uma boa alternativa ao Gatsby, é diferente, mas também tem coisas idênticas e como ainda está no contexto do [React.js](https://reactjs.org/) a mudança no código e na organização do projeto não acabaria por ser tão brusca. Posso dizer que o Next.js se mostrou como uma boa opção, seguindo a documentação oficial e alguns tutorials no Youtube o _refactor_ foi andando, claro, com algumas pequenas dificuldades pelo meio. Encontrar obstáculos na jornada não pode faltar no que toca a web development, presumo. Ao longo de todo este processo passou algo tempo e, entretanto, saiu o [Next.js 13](https://nextjs.org/blog/next-13), uma atualização significativa que trouxe uma série de funcionalidades novas e melhorias à _framework_. Dentro destas novidades só implementei a nova metodologia para incorporar Google Fonts no projeto com o _package_ [@next/font](https://nextjs.org/docs/basic-features/font-optimization). Uma das novas features mais interessantes, mas que não acabei por incorporar por estar em _beta_ é o novo diretório /app que revoluciona o desenvolvimento de um projeto de Next.js, resumindo, todos componentes/páginas são por default renderizados no servidor e só serão processadas no cliente se for usada uma _flag_ específica – “use client” – no início do ficheiro do componente/página. Resumidamente, ao desenvolver neste novo diretório, o /app, estamos a utilizar uma arquitetura de _islands_ (_islands architecture_), que já outras _frameworks_ oferecem, como o [Astro](https://astro.build/), [Fresh](https://fresh.deno.dev/), [Qwik](https://qwik.builder.io/) etc.

- [Islands Architecture](https://www.patterns.dev/posts/islands-architecture/)
- [Why You Should Use Islands Architecture](https://betterprogramming.pub/why-you-should-use-islands-architecture-b4f291708a02)
- [Interactive islands (Fresh)](https://fresh.deno.dev/docs/concepts/islands)
- [Astro Islands (Astro)](https://docs.astro.build/en/concepts/islands/)

Para além do Next.js, algo que também decidi explorar e implementar foi o [Typescript](https://www.typescriptlang.org/). Primeiramente era algo que me assustava, types em todos lados e erros em tudo o que era canto no código, mas penso que o processo de implementação poderia ter sido bem pior. Felizmente, o Typescript é uma linguagem já bastante utilizada na conceção de projetos e a comunidade também já produziu muitos conteúdos auxiliares educativos.

Deixo aqui alguns recursos que possam ser úteis para a transição do Javascript para o Typescript:

- [Migrating from JavaScript – Documentação oficial do Typescript](https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html)
- [A simple guide for migrating from JavaScript to TypeScript](https://blog.logrocket.com/a-simple-guide-for-migrating-from-javascript-to-typescript/)
- [Moving from JavaScript to TypeScript](https://dev.to/andrewbaisden/moving-from-javascript-to-typescript-40ac)

Relativamente à estilização, tentei fazer a minha vida mais fácil e incorporei o Tailwind CSS para me auxiliar na estilização do website. Bem, existem muitas opiniões da comunidade acerca do Tailwind, de ser um _anti-pattern_ no que toca à estilização visto que tira todos os estilos fora do css para o html e claro, também o número de linhas que um elemento de html fica no atributo das classes.

![Classes, classes em todo lado no HTML (Toy Story Meme) {caption: Classes, classes em todo lado no meu bonito HTML}](my-website-v2_classes-everywhere.png 'Classes, classes em todo lado no HTML (Toy Story Meme)')

Sendo bastante sincero, atualmente não existe uma forma ideal de estilizar um website tendo em conta o mar de opções que existem por aí fora, com as suas vantagens e desvantagens, quer seja para frameworks específicas ou para um website com html, css e javascript vanilla. [Bulmacss](https://bulma.io/), [Picocss](https://picocss.com/), [Bootstrap](https://getbootstrap.com/), [Unocss](https://github.com/unocss/unocss), [Windicss](https://windicss.org/), [Styled-components](https://styled-components.com/), [Stitches](https://stitches.dev/), [Rebass](https://rebassjs.org/), [Theme UI](https://theme-ui.com/), [Chakra UI](https://chakra-ui.com/), [Mantine](https://mantine.dev/), [Material UI](https://mui.com/), [Tamagui](https://tamagui.dev/), [Native Base](https://nativebase.io/), [NextUI](https://nextui.org/) e tantas outras alternativas. O Tailwind é mais uma opção de estilização com os seus prós e contras que podem diferir na sua quantia tendo em conta o contexto em que a ferramenta é aplicada.

A verdade é que, em pouco tempo e sem grande esforço é possível estilizar um website com o Tailwind de uma forma bastante intuitiva e fluída devido aos nomes das classes, da [documentação oficial](https://tailwindcss.com/docs/utility-first) e de recursos da comunidade, como o [Tailwind Elements](https://tailwind-elements.com/quick-start/), a _cheatseet_ do [tailwindcomponents](https://tailwindcomponents.com/cheatsheet/) ou a lista infindável de recursos relacionados com a framework no repositório, [awesome-tailwind](https://github.com/aniftyco/awesome-tailwindcss). Como cereja no topo do bolo, temos a extensão [oficial do VSCode](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss) que oferece _intellisense_ para os nomes das classes e o [_plugin_ do Prettier](https://github.com/tailwindlabs/prettier-plugin-tailwindcss) que ordena as classes de uma forma predeterminada e intuitiva o que torna todo este processo de desenvolvimento ainda melhor. Digo sem qualquer problema nenhum, não me sinto nada arrependido de escolher o Tailwind, ajudou mesmo bastante na estilização do website.
Considerando que o tema/conteúdo deste post não é necessariamente o Tailwind não irei abordar o assunto exaustivamente, por isso, para quem tiver mais interesse sobre o Tailwind, como utilizá-lo, os seus prós e contras e o que a comunidade pensa sobre esta ferramenta deixo uns _links_ abaixo para saciar a vossa curiosidade:

- [The pros and cons of Tailwind CSS](https://webartisan.info/the-pros-and-cons-of-tailwindcss)
- [Tailwind CSS is the worst…](https://www.youtube.com/watch?v=lHZwlzOUOZ4)
- [Why is everyone talking about Tailwind?](https://www.youtube.com/watch?v=gtb9OBhra5c)
- [I Wish I Knew This Way Earlier...](https://www.youtube.com/watch?v=QBajvZaWLXs&t=470s)

Por fim, passei para as questões de otimização, mais especificamente na performance e na acessibilidade, do website, tendo como guia a ferramenta _open-source_ [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) da Google. Todo este processo de tentar obter um score alto no Lighthouse foi cansativo, mas recompensador. Foram melhorados especialmente aspetos na performance das imagens do website e também em aspetos de acessibilidade dos elementos.

![Duas pessoas a apontar para o score do meu website no Lighthouse {caption: Olha para o meu score no Lighthouse! Wow!}](my-website-v2_lighthouse-score.png 'Duas pessoas a apontar para o score do meu website no Lighthouse')

Não posso deixar de mencionar que em relação a questões de acessibilidade o website ainda tem muito espaço para melhorias. É de referir ainda que durante este processo coloquei em causa algumas das minhas decisões no que toca à identidade do website, mais especificamente às animações que o website possuía. “_Será que devo retirar grande parte das animações da introdução na página inicial, que me tanto esforcei ao fazê-las com o [Framer Motion](https://www.framer.com/motion/), e nas outras páginas no geral?_” Foi a pergunta que fiz a mim próprio. Bem, a resposta foi sim e não, tentei diminuir o tempo das animações no geral e torná-las um pouco mais simples mas não retirá-las totalmente do website. Espero que as animações tenham ficado mais fluídas, menos intrusivas e, simultaneamente, mais agradáveis visualmente.
Bem, acho que é isto e nada mais, esperemos que o website esteja mais fluído e que a sua performance tenha aumentado e, mesmo que a diferença seja pouca para o navegador que está agora neste canto da web, ao menos acabei sempre por aprender vários aspetos do Next.js, do Typescript, do Tailwind CSS e de como otimizar a performance utilizando o Lighthouse.


o meu website v2


Bem, cá estamos, no meu pequeno canto da web que posso partilhar e mostrar o meu portfólio e derivados a outras pessoas, custou, mas valeu a pena.
Já vinha há um tempo com ideias de construir um website para alojar o modesto portfólio que fui criando ao longo dos primeiros anos da universidade, todavia foi só no terceiro ano que comecei realmente a avançar com esta ideia. Para meu fortúnio, acabei por ter uma unidade curricular que um dos trabalhos práticos para avaliação seria um produto (vídeo, website, catálogo etc.) que representasse a identidade do aluno tendo em conta o contexto profissional, logo, esta disciplina ajudou drasticamente na conceção do website, mas também na minha identidade visual. Claro, não foi de todo fácil, vários rascunhos e _drafts_ para a identidade visual, desde cores até logos, foram descartados ao longo do caminho e outros evoluíram com as diferentes críticas que os docentes da disciplina foram me fornecendo ao longo do tempo.

Deixando agora de lado a parte visual da identidade de lado, vamos falar do processo de implementação. Defini inicialmente os requisitos funcionais e principais do website, sendo eles a apresentação dos meus trabalhos, das minha competências e de um pequeno blog para escrever um ou outro _post_ às vezes. Tendo em conta esta lista de requisitos optei, sem grandes surpresas, pelo uso de uma _framework_ para a criação de todo o _front-end_ do site, sendo ela o [Reactjs](https://reactjs.org/). No entanto, como grande parte do website iria ser estática, visto que não existe qualquer tipo de informação dinâmica, pesquisei um pouco mais e descobri duas alternativas mais indicadas para o que tinha em mente, SSG (Static Site Generation), seriam o [Gatsbyjs](https://www.gatsbyjs.com/) e o [Nextjs](https://nextjs.org/), _frameworks_ ambas baseadas no React.

![Batalha entre gatsby e next no SSG {caption: A épica batalha entre gatsby e next no SSG}](my-website_gatsbyvsnext.png 'Batalha entre gatsby e next no SSG')

Acabei por escolher o Gatsby, pareceu-me bastante acessível na altura, principalmente devido à lógica de plugins e a vasta documentação que se encontrava disponível no website da _framework_. Talvez se começasse o projeto de zero hoje ficava pelo Next, ultimamente parece-me mais interessante, de qualquer das formas, não existem _frameworks_ perfeitas, todas têm os seus defeitos e virtudes, é o que é.
Após uma pesquisa de diferentes librarias e várias horas a ler documentação e a ver um ou outro tutorial lá consegui perceber a estrutura do Gatsby, principalmente as partes do [node.js](https://nodejs.org/en/) e do [graphql](https://graphql.org/), que ao princípio me deixaram um pouco perplexo e confuso. Passado uns dias já me encontrava a explorar a criação da lógica do blog e dos seus _posts_ que me levou-me a aventurar-me ao criar ficheiros _markdown_ para depois puder testar. Em primeiro lugar tive de criar as rotas dinâmicas para estes _posts_ no ficheiro gatsby-config.js, utilizando métodos nativos do node como o _path_ para obter todos os ficheiros de um diretório específico, neste caso dos posts em _markdown_, como é possível observar em baixo.

```javascript
exports.createPages = async ({ graphql, actions }) => {
  const { createPage } = actions
  const postTemplate = path.resolve(`src/templates/post.js`)

  const posts = await graphql(`
    query {
      allMarkdownRemark {
        edges {
          node {
            fields {
              slug
            }
          }
        }
      }
    }
  `)

  posts.data.allMarkdownRemark.edges.forEach(edge => {
    createPage({
      path: `/blog/${edge.node.fields.slug}`,
      component: postTemplate,
      context: {
        slug: edge.node.fields.slug
      }
    })
  })
}
```

Em segundo e último lugar, tive de fazer uma _query_ de todos os _posts_ existentes, para a página do blog e outra _query_ de somente três _posts_ para a página _home_, operações que foram realizadas com a ajuda do graphql, como podem ver no exemplo.

```javascript
const posts = useStaticQuery(graphql`
  query {
    allMarkdownRemark(sort: { order: DESC, fields: [frontmatter___date] }) {
      edges {
        node {
          frontmatter {
            title
            date
          }
          timeToRead
          html
          excerpt
          fields {
            slug
          }
        }
      }
    }
  }
`)
```

Nada muito complexo de atingir seguindo tanto a documentação do Gatsby ou ao ver um tutorial algures na web.
Tendo o blog já funcional, avancei para a página dos meus trabalhos, das minhas competências e, claro para a estilização do todo o website. Na parte dos trabalhos e das competências, primeiramente tive de ponderar quais trabalhos mostrar e quais são realmente as minhas aptidões mais fortes, e, então, foi mais uma questão de recolher conteúdo, desde texto, imagens, ícones, e, depois tratar dessa informação para tudo estar apresentável para o público. Posso dizer que a parte de estilização acabou por ser mais trabalhosa pois coloquei um desafio a mim próprio de não utilizar um _design system_ ([material ui](https://material-ui.com/), [chakra ui](https://chakra-ui.com/) etc.) ou uma libraria de css ([tailwind](https://tailwindcss.com/), [bootstrap](https://getbootstrap.com/)), são tantas as opções que acabo por ficar complementamente indeciso e até com dores de cabeça.

![Confusão a decidir um design system para escolher {caption: Tantos design systems para escolher que até faz a cabeça doer...}](my-website_designsystemheadche.png 'Confusão a decidir um design system para escolher')

Assim, lá tive de escrever várias linhas de css, bastantes mesmo. Ao início não organizei devidamente o css, mas, felizmente, reparei no erro que estava a cometer e comecei a prestar mais atenção a este aspeto, optando pelo uso de [sass/scss](https://sass-lang.com/) e criando uma estrutura de diretórios e com ficheiros específicos para cada página, componente, ou para uma lista de variáveis ou de _mixins_, etc., estratégia que adotei depois de pesquisar boas práticas para a organização de scss em projetos e ter visitado e lido alguns artigos de developers que partilhavam as suas estratégias. Deixo aqui os links, caso estejam curiosos:

- [Aesthetic Sass 1: Architecture and Style Organization](https://scotch.io/tutorials/aesthetic-sass-1-architecture-and-style-organization)
- [A Simple SCSS Architecture, and Best Practice Playbook](https://matthewelsom.com/blog/simple-scss-playbook.html)
- [How to structure a Sass project](http://thesassway.com/beginner/how-to-structure-a-sass-project)
- [Sass: Directory Structures That Help You Maintain Your Code](https://vanseodesign.com/css/sass-directory-structures/)

Para colocar a cereja no topo de bolo de criei várias animações simples e subtis utilizando o [gsap](https://greensock.com/gsap/) e também fui adicionando pequenas funcionalidades, como a mudança do tema, para _light_ ou _dark_, ou um botão de go back to top, para voltar ao topo da página rápidamente.
No final, posso dizer que foi um jornada divertida, descobri o mundo do Gatsby.js, que também me ajudou a perceber melhor o node e frameworks de React que utilizam o node para fazerem o render no lado servidor. Também explorei bastante o scss, criando de certa forma um _micro design system_ para o meu website. Ficou feito, claro, de certeza que ao longo do tempo sofrerá algumas alterações, umas mais drásticas e outras menos, mas pronto, agora ao partilhar um _link_ posso dar a conhecer a alguém o meu trabalho o que é deveras importante e útil para alguém que mais tarde ou mais cedo vai ingressar no mercado de trabalho.
É isso, espero que tenham gostado do pequeno texto acerca da jornada e também espero que apreciem o meu website.
Por agora encontramo-nos noutro _post_, até lá.
