Executando verificação de segurança...
16

Por que estão usando tanta coisa pra realizar tarefas simples?

Esse post é mais uma pergunta sincera do que algo mais elaborado.

Tenho percebido que muito programador iniciante tem escolhido muita tecnologia mainstream pra criarem coisas simples, como um portfólio, landing page, calculadora (até currículos).

Dentre esses projetos, vi pessoas usarem Typescript, React, AngularJS, Bootstrap, Tailwind CSS, SCSS/SASS, GitBash, Figma e mais alguma c%ralhada de coisas.

Tudo para coisas que qualquer um faria com um único arquivo index.html.

Vi alguns até embutirem bancos de dados nisso.

A minha sincera dúvida: por que?

Isso é culpa dos mentores? Dos cursos onde os aprendizes estão vindo? Estão complicando demais o que era para ser simples, principalmente se tratando de web. Quase todo o problema tem o Javascript e/ou Typescript envolvidos. Isso é para testar suas habilidades? Para testar os limites do computador ou o custo de desenvolvimento? Não sei.

Novamente: quem está ensinando os aprendizes que a tecnologia é tão complicada?

o que estão fazendo

14

A minha sincera dúvida: por que?

A tendência de complicar projetos simples com tecnologias avançadas não é nova, refletindo uma verdade que perdura no design desde sua concepção. A escola Bauhaus, entrou para história do design, justamente por promover a filosofia de que "a perfeição é finalmente atingida, não, quando não há mais nada a adicionar, mas sim, quando não há mais nada a retirar". Isso contrasta com a tendência natural ao over-engineering.
Sala de controle de um u-boat 1918
Sala de controle de um u-boat 1918

Mas, por que, indagamos, por que essa tendência natural ao labirinto, ao complexo, quando o simples aguarda, paciente, por sua vez?

A famosa resposta de um alpinista ao ser questionado sobre por que queria escalar o Monte Everest: "porque ele está lá", reflete essa tendência humana. Essa declaração ilustra uma atração quase primal pelo desafio, pela conquista.

Não é a busca pelo complicado em si, mas na exaltação da conquista, na adrenalina do desafio, no peito estufado pela sensação de domínio sobre o caos. Os desenvolvedores, esses designers do digital, veem nas linhas de código não apenas instruções, mas pinceladas de sua próprio intelecto. Quanto mais código, quanto mais complexo, mais bibliotecas, mais frameworks, mais ferramentas empilhadas com destreza em uma torre de Babel: maior e profunda a sensação de avanço, de progresso, de escalada rumo ao seleto grupo dos virtuosos da programação. É um delírio? Sim!

Esse delírio, de fato, reflete a própria natureza do capitalismo, onde nossa sociedade é moldada para promover um ciclo contínuo de consumo, superprodução e superengenharia. Esse impulso não apenas influencia o comportamento individual dos desenvolvedores, mas é também um reflexo das estruturas sociais mais amplas que valorizam o crescimento e a inovação constante, muitas vezes à custa da simplicidade e sustentabilidade.

A resposta ao "por que" dessa pergunta é comparável à por que destruir o meio ambiente em nome do progresso tecnológico? Ninguém tem uma resposta, mas na raiz de todas, está o capital: a plata, dinheiro, bufunfa. Reconhecer essa dinâmica é crucial para redirecionar práticas para soluções mais equilibradas.

Quem está ensinando os aprendizes que a tecnologia é tão complicada?

Os incentivadores dessa complexidade são muitos e variados, desde os vendedores de cursos, esses modernos alquimistas prometendo transformar o chumbo do desconhecimento em ouro puro da expertise, até os gigantes, os titãs, os colossos do mundo da tecnologia – Amazon, Microsoft, Google, e todos seus ilustres irmãos e irmãs, primos e primas que veem na complexidade não um problema, mas uma oportunidade lucrar alto!

Ao voltar nossa atenção para os provedores de nuvem, como AWS, GCP, Azure, esses gigantes, ganham com cada byte transferido, com cada ciclo de CPU consumido, com cada gigabyte armazenado. Eles nos encorajam, com sorrisos benevolentes e promessas de escalabilidade, segurança, eficiência, a complicar, a adicionar mais uma camada, mais um serviço, mais uma ferramenta, pois em cada camada, em cada adição, há uma taxa, um custo, e o pior, um fio invisível que nos liga a eles, drenando não apenas nossos recursos financeiros, mas muitas vezes nossa capacidade de ver a beleza na simplicidade e autonomia.


Não nos deixemos cair em tentação e livrai-nos do mal:

A chave para resistir eficazmente reside, sem dúvida, no discernimento. Esta capacidade inestimável de discernir nos possibilita avaliar com precisão se uma ferramenta ou abordagem realmente adiciona valor ao nosso projeto, ou se, ao contrário, apenas acrescenta uma camada de complexidade desnecessária. No entanto, a aquisição de tal discernimento segue um caminho longo e árduo, forjado pela experiência.

É através da jornada — um trajeto marcado por um acúmulo de experiências, falhas, sucessos, refatorações que desafiam nossa perseverança, e epifanias repentinas sob a água quente do chuveiro — que começamos, aos poucos, a perceber a verdade. Uma verdade tão absoluta quanto o teorema de Pitágoras, segundo o qual o quadrado da hipotenusa é igual à soma dos quadrados dos catetos; essa realidade apenas se revela após inúmeras noites de debugging e inspeção meticulosa, momentos que nos equipam com a bagagem necessária para dizer não às complexidades desnecessárias e abraçar o simples, o estúpido.

Entretanto, não devemos ceder a pressão. Mesmo diante deste cenário, existe espaço para a escolha, para o exercício do discernimento, para a prática da sabedoria. Podemos optar por aprender, sim, mas aprender a questionar criticamente: "Isso realmente simplifica o processo? Isso realmente adiciona valor? Isso beneficia a mim ou apenas contribui para engordar ainda mais os cofres dos gigantes tecnológicos?" A verdadeira maestria no design está em saber quando é hora de complicar e quando é hora de simplificar. E o caminho para a maestria é longo!

A analogia com o U-boat ilumina de forma única os desafios enfrentados na inovação e no design tecnológico. O primeiro submarino já construído: os engenheiros não tinham precedentes claros para guiá-los na determinação do que era essencial e do que não era. A tendência natural foi incluir o máximo possível de controles e funcionalidades, numa tentativa de preparar o submarino para o "desconhecido". Esse instinto de adicionar em vez de subtrair reflete uma cautela natural, mas também destaca uma verdade fundamental no design e na engenharia: a dificuldade em identificar o que é verdadeiramente necessário.

layers

9

To finalizando um projeto aqui em casa pra aprender a stack Java e tô usando "pacote completo", fazendo o bingo na cartelinha do Spring. E o objetivo é o que já foi dito em outro comentário: eu quero aprender a usar a ferramenta.

É um projetinho simples de consumo de uma API pública, gerar valor em cima desses dados e entregar na outra ponta em forma de API tbem.

É coisa que poderia muito bem ser trabalhada só no front, mas eu quero utilizar cada modulo do Spring, saber do que se trata.

Óbvio que no dia a dia o nível se complexidade é totalmente diferente, mas eu preciso saber que essas ferramentas existem e ter uma minima vivência com elas.

Agora, se, como dito em outro dos comentários, até em projetos reais de pequena complexidade está rolando overengineering, tá faltando senioridade de quem está tocando esses projetos. Treino é treino e jogo é jogo. E se na hora do jogo, existe uma solução eficiente, fácil e barata, esse é o sonho dourado que todos perseguimos.

4

"Resume-driven development". Colocar o máximo de coisas bacanudas num CV para mostrar que você está antenado na moda.

Afinal, shell script não vende, HTML estático escrito no vim não vende, site sem JavaScript não vende, self-hosting não vende, software livre e formatos abertos não vendem.

Tudo precisa ser grandioso e estar preparado para o dia em que a minha empresa bombar.

2

Eu concordo em partes, mas você parece negligenciar coisas importantes.

De fato, parte expressiva das soluções não requerem uso de ferramentas tão refinadas e complexas, onde soluções mais rápidas e simples seriam mais eficientes. Porém, uma boa maneira de comaçar um estudo de uma nova ferramenta, é usando-a para tarefas simples. Por exemplo, suponha que você quer aprender a atirar com arco e flecha, obviamente você não vai entrar em uma competição para aprender. Você vai começar de um jeito simples, mesmo que não seja a ferramenta ideal para disparos curtos, você vai começar atirando de 2-3m. Eu poderia jogar uma pedra no alvo? Sim, poderia, teria basicamente o mesmo efeito e de forma mais simples que aprender a atirar.

Entretando, compreende que para eu adquirir essa habilidade, eu tenha que começar usando-a de maneira simples, mesmo que não seja o uso mais eficiente dela?

6

Se fosse apenas limitado ao estudo eu não ligaria, mas percebo que estão levando isso além.

Já teve alguns casos de remover totalmente dependências somente pelo fato de alterar o conceito da implementação. Em um projeto recente vi o desenvolvedor usando Redis para cachear a resposta que enviava o arquivo. A alegação era que "ler o arquivo" em toda a requisição era custoso, e realmente era, então já tinham aprendido que Redis era uma forma eficiente de cache.

Resolvi o problema eliminando o Redis e fazendo streaming do arquivo. Sequer sabiam que existiam "streaming" de dados no HTTP. Isso é uma deficiência do conceito, algo que não ensinam.

Muitos não sabem o que é uma API. Sempre lembram daquele REST que lê/volta um JSON. Isso está errado.

Simplificar não é remover o conceito, o que estão fazendo é o contrário: estão dizendo que você precisa aprender tudo isso para resolver coisas simples e não ensinam o mais básico primeiro. Estão ensinando o que vem depois e estão pulando as aulas iniciais, ou sequer estão existindo essas aulas.

3

Cache é um dos erros que as pessoas mais cometem. É uma técnica extremamente complexa e difícil de prever o resultado, mesmo quando feito certo. É bem o caso de só usar quando for muito necessário e provar que precisa. É frequente ver casos que a solução para deixar mais rápido é tirar o cache. Isso é diz muito sobre o estado da nossa indústria.

1
2

cara eu vinha lutando pra criar meu portifolio pq queria fazer exatamente assim com estas tecnologias, ate q eu percebi que tava perdendo tempo, implementei tudo de forma basica mesmo e cheguei num resultado agradavel do que eu queria, os efeitos usei uma lib simples de js, super facil de aplicar, e pronto...

2

Tem coisas que a gente só aprende com o tempo, over-engineering é uma delas.
Porem, no meu ponto de vista, não tem nenhum problema desenvolvermos projetos pessoais que servem como estudo com tecnologias mais robustas, até pq os projetos de estudos tem como objetivo estudar algo novo. Se eu quiser desenvolver algo onde o objetivo principal seja gerar algum valor, ai sim eu usaria o mais simples para gerar resultados, e iria aumentando acomplexidade aos poucos, mas quando o objetivo é só estudar, programar por hobbie, então não tem problema.
No fim, independente da tecnologia utilizada, o dev vai estar ganhando repertório e adiquirindo conhecimento.

2

Mano, minha sincera opinião

Um iniciante (ou até mais avançado) usa tudo que pode e muito mais simplesmente para aprender, ou pelo menos tentar, provar, colocar o pé no mar que é um framework. Está errado? Depende

Em projetos feitos em laboratório eu defendo o uso de tudo que é lib e framework, pra que a pessoa possa testar e se atualizar, e até mesmo se divertir. Eu estava pensando em criar um protótipo de rede social que usasse tudo que é forma de comunicação pela simples explicação de "porque sim". Aprendi coisa demais, Kafka, AWS Lambda, profiling, elastic search, e por ai vai.

Agora, no dia a dia do trabalho, eu prezo 100% pela praticidade. Todo projeto que toco no trabalho uso aquilo que já estou cansado de ver, da forma mais simples possível. Isso garante que merdas não aconteçam em produção (não muitas pelo menos)

É tipo, por que você usa uma espada para cortar pão?
Você está com fome e com pressa, e precisa ser rápido e preciso naquilo que você faz? Se for isso, é burrice.
Agora, você está testando sua espada nova e legal, e só tem um pão pra cortar? Vai fundo

1

Mano acho que seu comentario simplificou muito meus pensamentos de maneira geral, as vezes eu preciso aprender coisas diferentes , independente se é a forma mas pratica ou não eu vou saber depois que aprender e tiver mas conhecimento.

2

Cara, tenho o mesmo pensamento... Por quê!!!!?
Por que raios as pessoas estão fazendo over engineering, de telas de formulário simples e básicos, alguns projetos são portifólios ou telas bobas de cadastros.
Ok, tem projetos que são usados para demostrar o conhecimento em certos assuntos etc e tal. Mas tem outros que é o mais puro over engineering, já vi várias aplicações que possuem praticamente zerooo usuários e que no final do mês não pagos custos da cloud.

2

TL;DR - Pra treinar/aprender e mostrar o que se fazer

Levo meu website pessoal como meu playground de novas tecnologias, é ele que uso pra poder testar novas tecnologias e conceitos e saber até onde da pra ir. Aprender quando coloquei coisa demais nele sem precisão faz parte de ter esse ambiente de aprendizado. Uma coisa muito simples não tem muito aprendizado e o desafio não é tão grande.

Meu portifólio, como porta entrada pra me conhecerem, pode ser por si só, uma oportunidade pra mostrar o que sei fazer :)

1

eu acredito que seja por conta do conhecimento agregado e pra manter as aparencias.
é igual empresas de tech pequenas e medias nao usarem wordpress pro site ou blog, mesmo que esse site/blog seja simples e muito mais facil de fazer em um CMS pronto.
meio que isso gera uma impressão ruim.
eu mesmo estava criando um projeto besta sem qualquer intuito de lucrar. fiz em html basico e com backend em nodejs, bem vanilla sem frameworks complexos. apenas um express entregando html, css e js.

funcionou bem por um tempo. ate começar a ganhar certa notoriedade no publico alvo e começar a me dar dor de cabeça pra corrigir erros e expandir a ideia.

nao tinha planos de transformar em um negocio, mas acabou virando um SaaS.
Resultado: tive que refazer do zero usando nextjs e outros frameworks e soluções prontas pra evitar transtornos futuros.

então a ideia é, faça da melhor forma logo do inicio.

2
-2

e como era a web antes deles? um monte de HTML estático feio. ou então uns sites pesados cheio de código mal estruturado e com loading eterno.
esses framework surgiram diante de uma necessidade, por isso são famosos, porque souberam sanar o problema muito bem.

teve um tempo que eu também não curtia, queria reinventar a roda e fazer tudo manualmente, hoje eu percebi que é perda de tempo. use as ferramentas ao seu alcance.

1

Essa é a pior desculpa que vi.

Recomendo que reveja todo o conceito de desenvolvimento. Tudo esse monte de tranqueira Javascript compila para um monte de HTML estático e feio. É andar na contramão de sustentabilidade e pensar em trazer prejuízos para seu cliente no futuro.

Frameworks quase nunca surgem por necessidade. Alguns surgem para resolver problemas que eles mesmos inventam. O fato de ser famoso não é relacionado com sua qualidade. Tem um monte de influencer no TikTok e Instagram.

1

Frameworks quase nunca surgem por necessidade

Discordo do trecho "quase nunca", os frameworks existem para resolver ou otimizar a resolução de um problema, hoje existe uma grande quantidade de diferentes frameworks que fazem a mesma coisa, porém, com abordagens diferentes, e vai do gosto do desenvolvedor optar por um de acordo com sua necessidade.

0

irmão, se é desculpa ou não, não muda o fato de que ganhou fama e é adotado pelo comunidade em peso.

não julgo se vc não curte ou não acha certo, cada um tem sua opinião, eu inclusive pensava assim anos atrás. mas o fato é: se um framework é adotado por milhares, alguma coisa boa deve ter, se não, não teriam empresas investindo no desenvolvimento deles.

vejo seu comentário mais como uma opinião pessoal sua do que como uma crítica embasada em algo.

2

É sim embasada, mostro isso nos outros comentários.

Frameworks populares e aceitos pela comunidade tem seus usos. Na documentação de cada um é descrito o que ele é e o que não é, mas é errado entendermos que qualquer tecnologia popular serve como um martelo de ouro.

A crítica é exatamente sobre usar ferramentas feitas para resolverem problemas complexos mas para situações simples que não precisam de tal coisa. Se for algo complexo, use o NextJS, não vejo problema nenhum em usar.

Esses frameworks são quase todos voltados à receita de bolo. Boas empresas e cargos não querem copiadores e coladores de código, querem desenvolvedores que resolvam problemas. Esses frameworks não resolvem todos os problemas. É papel do desenvolvedor reconhecer isso.

3

pra criar uma landing page simples, apenas com uma foto de um produto, um texto curto e um link logo abaixo redirecionando pra um produto em algum marketplace, vc acha que é mais fácil oq?

opção 1: fazer com HTML/css/js puro, estilizar tudo manualmente e depois subir um servidor web basico, apontar um domínio, configurar ssl e por em produção.

opção 2: iniciar um projeto next, criar a página estática, usar algum pacote de componentes estilizados, subir no github e depois hospedar automaticamente na vercel já com domínio e ssl?

entende onde quero chegar?

o cliente quer a solução do problema, só isso.

concordo que o dev tem que aprender a forma manual da coisa, ter contato com o "arroz e feijão", mas depois disso, acho muito mais produtivo usar soluções prontas e frameworks completos pra produzir algo, pq da feita que vc pega o ritmo, se torna extremamente prático e eficiente.

0

Landing page (que é um dos assuntos que o autor levantou na postagem inicial) sempre existiu, independente disso, vai me dizer que html, css e js nao toca bem uma lp ou até mais.
Agora querer reescrever o Fb vanilla ai sabemos que nao dá, mas tbm sabemos quanto tempo de desenvolvimento e grana tem aportado num projeto assim.E eu acho esse foi o ponto do autor, fazer coisas simples de maneira complicada.
Enfim..

-2

uma landing page pode ser desde uma página simples com texto e imagens e links diretos, como também um funil de vendas com algum esquema de pagamento, contato direto via chat (aquele famoso botaozinho flutuante lateral) e etc. tudo vai depender da complexidade do projeto.
dei meu exemplo pq foi justamente por achar que era algo simples eu fiz em HTML cru, depois tive que refazer do zero usando tecnologias mais escaláveis.

e cara, convenhamos, até pra fazer uma landing page simples não é difícil usando um next.js por exemplo, porque não usar?

1

A explicação é muito simples: é para mostrar que sabe.

Sabe o "talk is cheap, show me the code?" Então, muito melhor do que dizer que sabe React é fazer alguma coisa em React. Mas não vão fazer um projeto sério e complexo onde React efetivamente seria uma ferramenta útil e/ou necessária. Vão fazer um portfólio cheio de animações desnecessárias.

Daí fica essa impressão de overengineering, que não deixa de ser mesmo. Mas é importante pensar no nível técnico e de experiência da pessoa antes de sair julgando e descartando o coleguinha, senão você vira só um babaca que gosta de inventar desculpa para fingir que é superior. É como um valentão que acredita ser forte porque unicamente compara sua força com crianças 3 anos mais novas.

Não vou usar a régua que eu uso para falar mal de gente com 20 anos de XP na área, para falar mal de um jovem que nunca trabalhou na área e tá fazendo o possível para arrumar o primeiro emprego.

1

Já falei isso aqui nesse post, mas o problema não se limita aos estudos. Na verdade, para mostrar que sabe realmente não é um problema. O real problema é querer aplicar isso para qualquer situação comercial.

Muitos destes aprendizes estão aprendendo dessa forma e entendendo que é a forma certa a fazer em qualquer coisa no mundo afora. Isso é problema com quem decide as tecnologias de um projeto, que a maioria das vezes não sabe decidir, mas por modismo quer pegar algo complicado suficiente para realizar algo simples.

Falei e dei exemplos disso em outros comentários do mesmo post.

1

Acredito que boa parte desse overengineering em projetos de iniciantes em programação ocorre devido à pressão dos entrevistadores para que apresentem projetos complexos em seus portfólios.
Nessa dinâmica, um projeto index.html não chama a atenção dos entrevistadores.
Portanto, o iniciante se preocupa mais em mostrar que sabe fazer algo com certo nível de complexidade do que em utilizar uma tecnologia adequada para um site simples.

0

Não concordo com vc. A pessoa quer mostar que sabe fazer coisas boas e complexas pq quem faz o mais sabe fazer o menos. Se eu to mostrando que sei fazer coisas complexas no meu portfólio, qual o problema disso? Não deveria ser bom? Esqueça a era que um programador poderia saber HTML, CSS e o básico de javascript. Depois do chatgpt e a enxurrada de devs procurando emprego na bolha dev, ninguém vai ligar pro seu portfolio em HTML básico... Até um react já não é o suficiente...

4

Eu vejo um portfólio com HTML e CSS como um grande potencial para um desenvolvedor. Ele é capaz de resolver um problema da forma mais simples e mínima possível.

Deixa sim de ser bom. Passa a se tornar desenvolvimento orientado à tendências. Usar uma tecnologia deve ser apenas quando faz sentido usar ela e não porque todo mundo faz assim. É usar efeito manata para desenvolver o software, o que o resultado nunca fica bom.

Você não está mostrando que sabe fazer coisas complexas, está mostrando que apertar um parafuso usando uma caixa de ferramentas inteira, mas não sabe usar a chave de fenda.

Usar React faz sentido onde deve ser usado. Usar HTML/CSS/JS puro faz sentido onde deve ser usado. Não faz sentido nenhum usar um monte de tecnologia para fazer um site simples. Isso só mostra que a pessoa sabe seguir receita de bolo mas não sabe resolver um problema. Nunca vai ser um desenvolvedor de softwares dessa forma, apenas um programador.

Desenvolvedor de softwares resolve problemas. Programadores digitam códigos.

4

E o projeto é complexo? Se for, eu concordo. Se for algo simples enfiando um monte de coisa sem sentido só mostra que a pessoa é ingênua e complica as cosias desnecessariamente. Ela pode conseguir emprego em um lugar que essa seja a regra, mas não nos melhores lugares. Inclusive porque usar algo mecanicamente é fácil, difícil é fazer com sentido. A maioria dos lugares não querem copiadores e coladores.

Por que não fazer as duas coisas? Até porque fazer algo com menos tecnologias está longe de ser simples, a não ser que a pessoa pense simploriamente. O que eu mais vejo, em várias áreas, é as pessoas não saberem fazer o menos, a rruma toido tipo de desculpa pra isso.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

4

Só para discordar um pouco. :D
O projeto é complexo? Sim.
Pode ser simplificado? Sim.
Então, a versão mais simples é a correta.

image

Vale baixar aquele livro velho (1984) Thinking Forth só pelas figuras.

De qualquer forma me lembro (deves ter passado por algo parecido) quando surgiu ttf e impressão colorida. O pessoal mandava currículo com quatro cinco tipo de fontes diferente e diversass cores.

-1

Meus 2 cents...
Acho que no final do dia, o importante é se entrou grana no seu bolso ou não (pensamento de pai de familia, se voce se preocupa com cooler RGB nao vai entender.) Dai, querer mostrar isso ou aquilo para comunidade, mano f***-se, a 10 anos atras quando eu só programava pra microcontroladores, entrou uma demanda (boa $$), que precisaria de um supervisório, corri no yt aprendi um winForm da vida, codei uma monolito enorme, até que nao foi dificil, atendeu o cliente e fim. SE eu usei x, y ou z pra fazer, pouco importa.
Tenho um amigo com um site, um Saas de anuncios (mais vanilla impossivel kkk e bem tosco por sinal, imagens quebradas etc...) que rende perto de 10k pra ele com um custo baixo.
Quem fica querendo aprender todo e qualquer frame do momento, vai saber todos e não ser bom em nenhum.
E esse papo ja rolou aqui no TN no passado se nao me engano.
Muito mimimi, cansado desse papo, ngm quer mais fazer nada na mão, (ai da trabalho) mano, quando eu compilei meu primeiro codigo pra uC pic no CCS free, era tudo na unha, mas meu alvo era o cheque do cliente me esperando, e não ter um repositório legal (nem tinha git naquela epoca).
Usar lib´s que facilitam, sim ajuda e muito, nao sou troxa tbm, mas viver pra aprender novos framewroks a cada 3 meses ai não.

2

Isso é fato. O cliente não quer saber se o projeto foi feito com NextJS ou HTML puro.

Tem que resolver o problema dele e ser viável para o desenvolvimento.

Quem fica querendo aprender todo e qualquer frame do momento, vai saber todos e não ser bom em nenhum.

De fato. Eu gosto de me especializar em uma tecnologia só, me sinto seguro em pegar qualquer coisa que consigo resolver com ela.

-1

Se você acha que usar apenas Figma, Sass ou Tailwind, TypeScript e React para criar um portfólio de qualidade é muita coisa, então precisa rever seu conceito de "muita coisa". Por que deveria me limitar a um único index.html quando posso dividir todas as seções do meu portfólio em componentes usando React e facilitar sua estilização com Sass? Sério, não vejo outra desculpa além de: "Não quero estudar isso, só quero aprender o mínimo necessário para fazer isso funcionar". Além disso, por que não criar previamente todo o protótipo do meu portfólio usando o Figma para facilitar o desenvolvimento posterior?

3
0

Não, esse portfolio não é melhor do que qualquer outro, muito pelo contrário (O que realmente é bom é o dono dele). vc queria mesmo que um desenvolvedor de OS (o dono do portfolio mencionado) criasse um portfolio focado em design? Não faz o menor sentido. Nesse caso, ele preferiu simplesmente não dar importancia a isso por que com o que ele trabalha não tem qualquer relação com isso.

2

Colega, creio que você não entendeu o meu ponto. O melhor portfólio é aquele que gera interesse no seu trabalho, tão simples quanto isso. Este cumpre essa função com excelência. Para um desenvolvedor web, a ideia é passar uma mensagem distinta, como no icônico portfólio do carrinho de Bruno Simon. Não faz sentido comparar qual é melhor; ambos são impecáveis. Eles transmitem uma mensagem clara, e isso é o ponto. Todo o resto é supérfluo. Todo o resto é excesso.