Comecei a refatorar o frontend do DMarkInfoBlog esta semana, trabalhando no projeto depois do expediente. Era uma mudança que eu vinha adiando havia bastante tempo porque, embora o blog estivesse funcional, sua interface ainda carregava aquela aparência muito característica dos projetos Laravel construídos quase inteiramente com Bootstrap. Finalmente resolvi colocar a mão na massa e atacar uma parte do sistema que sempre me incomodou.
O problema não estava em alguma falha funcional do Bootstrap. O framework cumpria bem seu papel, entregava responsividade e permitia montar telas rapidamente, mas a interface havia ficado dependente demais de seus componentes padrão. Cards, tabelas, formulários, botões, menus e mensagens utilizavam praticamente a aparência original da biblioteca. Como o projeto possuía pouca personalização visual, o resultado era uma interface rígida, quadrada e muito semelhante a um painel administrativo genérico. Qualquer tentativa de modernização exigia sobrescrever diversas classes ou criar exceções espalhadas pelas views. Em vez de continuar acumulando remendos sobre uma base que já não me agradava, decidi substituir a camada visual e reorganizar o frontend de forma mais consistente.
Desde o início, defini que essa refatoração não poderia interferir no backend. O DMarkInfoBlog já possuía rotas, controllers, autenticação, filtros, paginações, relatórios, geração de PDF, gerenciamento de usuários, edição de posts e registro de visitas funcionando corretamente. Não havia motivo para alterar regras de negócio apenas porque o framework visual seria trocado. Por isso, concentrei o trabalho dentro do diretório resources, preservando os nomes dos campos, métodos HTTP, tokens CSRF, variáveis Blade e contratos existentes entre as views e o Laravel. A aplicação continuaria sendo a mesma do ponto de vista funcional; o que mudaria seria a forma como esses recursos seriam apresentados.
A migração do Bootstrap para o Materialize
Escolhi o Materialize como nova base visual porque queria trabalhar com uma abordagem inspirada em Material Design sem precisar desenvolver todos os componentes do zero. A intenção não era simplesmente trocar uma biblioteca por outra e manter a mesma organização anterior. Aproveitei a migração para revisar espaçamentos, hierarquia tipográfica, proporções, comportamento dos cards, organização dos formulários e adaptação das páginas para telas menores. O Materialize passou a fornecer a estrutura dos componentes, enquanto um CSS próprio ficou responsável pela identidade visual do blog.
Uma restrição importante apareceu logo no início: o servidor de hospedagem não permite executar npm, Vite ou qualquer processo de compilação diretamente no ambiente de produção. A primeira solução baseada no fluxo tradicional de assets do Laravel não seria adequada para esse cenário. Reorganizei então a implementação para carregar o Materialize, os ícones e as fontes por CDN, eliminando a necessidade de executar npm install ou npm run build no webhost. O JavaScript responsável pelos componentes da interface também passou a ser carregado diretamente, permitindo publicar a refatoração apenas com a substituição dos arquivos necessários.
O layout principal foi um dos primeiros pontos alterados. A navbar do Bootstrap foi removida e reconstruída com os componentes do Materialize, mantendo exatamente os mesmos links, permissões e condições de autenticação existentes. No desktop, o usuário continua acessando dashboard, posts, usuários, relatórios e logout pelo menu superior. Em dispositivos móveis, a navegação utiliza uma sidenav própria, evitando que os itens sejam comprimidos ou quebrados. A logo original foi preservada e recebeu dimensões específicas para desktop e celular, mantendo seu destaque sem comprometer o alinhamento do menu.
O sistema de tema claro e escuro também foi mantido. A implementação anterior dependia do atributo data-bs-theme, específico do Bootstrap, então substituí essa dependência por um atributo neutro controlado pelo JavaScript da aplicação. A preferência continua armazenada no localStorage e pode respeitar o tema configurado no sistema operacional quando ainda não existe uma escolha salva. Cores de fundo, textos, bordas, superfícies, sombras e elementos de destaque passaram a utilizar variáveis CSS, permitindo que toda a interface responda ao tema de forma consistente.
A revisão das páginas públicas e administrativas
Na página inicial, mantive os filtros por título, conteúdo, autor e data, mas reorganizei o formulário utilizando o grid do Materialize. A listagem de artigos passou a trabalhar com duas colunas em telas maiores e uma coluna em dispositivos móveis. Os cards receberam altura mais consistente, espaçamento interno melhor distribuído e tratamento adequado para as imagens. Título, resumo, autor, data e botão de leitura continuam consumindo exatamente os mesmos dados enviados pelo backend. A mudança ficou restrita à apresentação, sem modificar consultas ou parâmetros de busca.
A página interna do artigo também passou por ajustes específicos. A imagem principal, o autor, a data, o conteúdo completo e os links de compartilhamento foram preservados. Os tooltips que dependiam da API JavaScript do Bootstrap foram substituídos pelos componentes equivalentes do Materialize. O título do post ganhou uma regra responsiva própria, pois seu tamanho inicial estava exagerado, principalmente no celular. Agora ele continua tendo destaque no desktop, mas diminui proporcionalmente em telas menores e quebra corretamente mesmo quando o texto é longo. Os botões de compartilhamento também foram reorganizados para não ultrapassarem a largura disponível.
Nas áreas administrativas, a preocupação principal foi preservar a densidade de informação sem voltar ao visual rígido anterior. O dashboard continua exibindo totais de posts, usuários e visitas, além dos filtros de período, opções de ordenação e gráfico construído com Chart.js. Os indicadores foram convertidos em cards responsivos e o gráfico recebeu um contêiner próprio para manter suas proporções. As tabelas passaram a utilizar rolagem horizontal quando não existe espaço suficiente, evitando que colunas, ações e textos sejam comprimidos de forma ilegível no celular.
A seção de relatórios exigiu um tratamento semelhante. Os filtros de data, os indicadores de visitas humanas e bots, os links para geração de PDF, a exclusão dos registros filtrados e a tabela de resultados foram mantidos. Campos extensos, como User Agent, passaram a aceitar quebra controlada de texto, enquanto a tabela permanece navegável horizontalmente em telas pequenas. As ações continuam utilizando as mesmas rotas e métodos HTTP definidos no backend. Nenhuma regra de retenção, exclusão ou geração de documento foi modificada durante a refatoração.
As telas de gerenciamento de posts e usuários também foram adaptadas ao novo padrão. Listagem, criação, edição, visualização e exclusão continuam disponíveis, com os mesmos formulários, validações e permissões. O CKEditor foi preservado nas telas de conteúdo e tratado separadamente, já que ele substitui o textarea original e não deve herdar automaticamente todos os comportamentos do Materialize. Login, cadastro, recuperação de senha e redefinição de senha também receberam a nova identidade visual sem qualquer alteração no fluxo de autenticação.
Ajustes de responsividade, paginação e usabilidade
A responsividade precisou ser revisada em cada componente, e não apenas no grid geral. Menu, logo, títulos, cards, tabelas, formulários, imagens e grupos de botões possuem comportamentos diferentes conforme a largura disponível. As antigas classes do Bootstrap, como col-md-6 e table-responsive, foram removidas das views ativas e substituídas por estruturas compatíveis com o Materialize e por regras próprias de CSS.
As paginações também foram refeitas porque o template anterior utilizava classes específicas do Bootstrap. Criei um padrão único para a página inicial, gerenciamento de posts, usuários e relatórios. O componente passou a exibir a página atual com destaque, controles de anterior e próxima, números intermediários e reticências quando necessário. As URLs continuam sendo geradas pelo paginator do Laravel, preservando automaticamente os parâmetros de filtro e ordenação. No celular, os controles ficam mais compactos e podem ser navegados sem quebrar o layout.
O formulário de sugestões recebeu atenção especial durante a revisão. O textarea original estava pequeno demais tanto no desktop quanto no celular, tornando desconfortável escrever uma mensagem mais longa e revisar o que já havia sido digitado. A altura foi ampliada, o redimensionamento vertical foi habilitado e os estados de foco, borda e contraste foram ajustados para os dois temas. Os identificadores dos campos também foram revisados para garantir a associação correta entre inputs e labels.
Durante a migração, também removi chamadas JavaScript que dependiam diretamente do Bootstrap e substituí a inicialização de dropdowns, sidenav e tooltips pelos recursos do Materialize. O Chart.js e o CKEditor foram mantidos porque são bibliotecas independentes do framework visual. O arquivo antigo do layout permaneceu apenas como backup e não participa da renderização atual. Isso evita carregar duas bibliotecas de interface ao mesmo tempo e reduz a possibilidade de conflitos entre seletores, eventos e estilos.
Outro ponto importante foi centralizar as decisões visuais. Antes, boa parte da aparência vinha diretamente das classes do Bootstrap e alguns ajustes estavam espalhados dentro das próprias views. Agora, cores, espaçamentos, tamanhos de títulos, comportamento dos cards, tabelas, paginações e formulários estão concentrados no CSS da aplicação. Essa organização facilita futuras alterações porque reduz a necessidade de procurar regras duplicadas em vários arquivos Blade.
O resultado não foi apenas uma substituição de Bootstrap por Materialize. A principal mudança foi retirar o DMarkInfoBlog da dependência quase total da aparência padrão de um framework. A interface agora possui uma camada visual própria, mas continua aproveitando componentes prontos para navegação, responsividade e formulários. Isso cria um equilíbrio melhor entre velocidade de desenvolvimento e identidade visual, sem transformar a manutenção do frontend em um conjunto de componentes desenvolvidos do zero.
Do ponto de vista do backend, praticamente nada mudou. Rotas, controllers, autenticação, consultas, paginações, relatórios, geração de PDF, filtros, gerenciamento de usuários e persistência continuam funcionando da mesma maneira. Essa separação foi importante porque permitiu evoluir a experiência visual sem introduzir riscos desnecessários nas regras de negócio. A refatoração permaneceu concentrada na camada que realmente precisava ser alterada.
Ainda existem detalhes que certamente serão ajustados conforme eu utilizar o blog no dia a dia e observar o comportamento em diferentes resoluções. Refatorações de interface raramente terminam na primeira versão, principalmente quando envolvem páginas públicas e administrativas com necessidades distintas. Mesmo assim, a base agora está muito mais organizada, consistente e preparada para evoluir sem voltar ao mesmo acoplamento visual que existia anteriormente.
Depois de bastante tempo adiando essa mudança, finalmente retirei do caminho uma das partes que mais me incomodavam no DMarkInfoBlog. A aplicação continua sendo o mesmo projeto Laravel que venho desenvolvendo, mas deixou de carregar aquela aparência engessada e quadrada que vinha diretamente do Bootstrap. O frontend agora representa melhor o estágio atual do blog e, principalmente, tornou-se uma base mais agradável para continuar trabalhando após o expediente.