Explicando a diferença entre um framework e o código puro

Há um assunto que vejo aparecer com muita frequência: muita gente se perguntando qual é a melhor opção para começar a programar hoje em dia.
Justamente comecei a escrever este tópico em relação a este outro:
No qual o colega não tinha muito claros os princípios que giram em torno do mundo da programação hoje em dia.

Este artigo que escrevo a seguir só tenta simplificar para poder explicar melhor a diferença que existe entre uma linguagem de programação (PHP, Java ou Phyton) e um Framework (Laravel, Symfony, Spring, Struts ou Django)

Neste caso vou me concentrar no PHP, já que é o tema do tópico que tomei como referência. Mas é possível substituir onde digo PHP por Java ou Python, e onde digo Symfony, por Spring ou Django)

Em primeiro lugar é preciso deixar algo claro: uma coisa é a linguagem de programação e outra é a estrutura que gira em torno dessa linguagem

PHP é a linguagem de programação que dá sentido a tudo.

Mas, uma vez que você começa a conhecer como o PHP funciona em sua essência, dependendo do que você quiser fazer, acabará percebendo duas coisas:

1. É muito difícil manter o código (isso acontece em TODAS as linguagens, não é algo exclusivo do PHP)
2. É muito difícil compartilhar o código (igualmente, isso acontece em todas as linguagens

(entre tantas outras)

Então, ao longo da história, foram propostas várias soluções:

Geralmente a solução NÚMERO 1 é a "documentação do código". Quanto mais documentação, mais fácil será retomar um projeto que você passou 1 ano sem tocar, e mais fácil será que outra pessoa colabore ou possa trabalhar com o seu código.

Mas também surgiram outras propostas para resolver esses dois problemas. Uma delas são os famosos Frameworks Modelo-Visão-Controlador ou MVC. Esses frameworks permitem criar todo um novo mundo de métodos e construções em torno de uma linguagem já existente e resolvem esses dois problemas mencionados anteriormente basicamente fazendo com que tudo o que você programar tenha uma ordem bastante estrita.

Existem muitos Frameworks, como todos os que mencionei em mensagens anteriores, mas Laravel e Symfony são os mais populares. Quando eu falo de aprender Laravel, não digo que o PHP deva ser abandonado. Porque, se não se tem amplos conhecimentos de PHP, basicamente NÃO SE PODE UTILIZAR o Laravel.

Laravel é um framework que se fundamenta na linguagem de programação PHP.

O problema é que programar em PHP do 0 é algo muito arcaico, é coisa de programador de nível muito baixo. Ou seja: pegar um arquivo em branco e começar a programar ali sem mais nem menos é, hoje em dia, um erro muito grande, salvo casos pontuais, como quando o objetivo é fazer um microsserviço muito simples

Seguindo na linha do PHP, há mais opções, mas uma muito popular é o Wordpress, e ao mesmo tempo muito desprezada. A maioria dos programadores novatos pensa que o Wordpress é um sisteminha simples para facilitar a vida de quem não sabe programar. Mas isso acontece porque a maioria das pessoas não dedicou tempo para se aprofundar na estrutura do Wordpress, a qual, com o tempo, acaba se parecendo até com a de um Framework como Laravel e Symfony.

Em primeiro lugar é necessário esquecer o backend e o típico de quando alguém instala um Wordpress.
Aqui eu vou me concentrar no Codex: https://codex.wordpress.org

Wordpress, como tudo nesta vida, tem várias vantagens e desvantagens
Wordpress é PHP 100%, isso está claro.
Portanto, se você sabe programar em PHP e entende o codex do Wordpress, começará a criar coisas novas em questão de dias.

Sua principal vantagem é, ao mesmo tempo, sua principal desvantagem: A comunidade. A comunidade oferece um milhão de soluções que simplificam qualquer trabalho. Mas muitas delas estão muito mal programadas, portanto, se você escolher mal, pode atrasar seu trabalho. Há centenas de soluções incrivelmente boas, e outras tantas milhares que são um lixo. Com experiência, a gente aprende a selecionar corretamente e ficar com o melhor.

E isso tem a ver com um dos principais problemas que existem no mundo da programação: voltar a programar o que já foi programado por outros.

Um exemplo

Imagine que você quer fazer um site que vai ser uma casa de apostas esportivas.

Para este exemplo vou tomar três alternativas:

1. Fazê-lo em PHP puro, do 0.
2. Utilizar um Framework como Symfony
3. Utilizar Wordpress

Vamos propor uma série de componentes fundamentais que a casa de apostas deve ter:

1. Um sistema de usuários
2. Um sistema de pagamentos
3. O sistema de apostas em si
4. Uma ligação com algum sistema que colete as partidas automaticamente de diferentes fontes via REST
5. Uma API para poder oferecer a informação a um App que construiremos no futuro para Android e para iOS

E com certeza haverá várias outras coisas que estou esquecendo, como o relativo ao frontend.
Mas, para simplificar ao máximo, vamos ficar com esses 5 componentes por enquanto.

Se você começar a programar em PHP puro, vai ter 5 problemas: ter que criar os 5 elementos praticamente do 0.

Em contrapartida, se decidir ir com Symfony ou com Wordpress, já tem metade do caminho feito:

1.O sistema de usuários: Ambas as plataformas oferecem um sistema de usuários bastante potente, totalmente testado e com risco muito baixo de ataque (injeções de SQL principalmente). Além disso, incluem opções para integração de login social em questão de minutos. Em contrapartida, se você tiver que programar isso em PHP puro do 0, vai demorar um tempão

2. O sistema de pagamentos: mais do mesmo: paypal, stripe, etc... todas já têm integrações para ambos os sistemas. Exemplo para Symfony: https://jmspaymentcorebundle.readthedocs.io/en/stable/

Embora existam bibliotecas para PHP que facilitariam um pouco esses dois elementos se você decidir ir pelo caminho do PHP puro, a manutenção dessas bibliotecas é totalmente odiosa. Talvez isso pudesse ser resolvido com o Composer, mas, mesmo assim, com um nível de integração muito baixo, as longas horas de programação estão garantidas, frente aos poucos minutos com os quais você consegue o mesmo resultado com Symfony ou Wordpress.

Pela minha experiência, mal consigo contar nos dedos de uma mão as vezes que vi um programador de PHP puro usar um gerenciador de repositórios tipo Composer. Por quê? Porque começar com PHP é um claro indício de novato. Aquele que já se dá ao trabalho de incorporar um repo automaticamente vai pensar em dar um salto para um Framework por motivos óbvios. O passo não é fácil, mas o esforço de aprender a utilizá-lo vale a pena.

3. O sistema de apostas: Não existe um sistema de apostas bom nem para Wordpress nem para Symfony, obviamente. Este é o elemento mais diferenciador da nossa página, portanto teremos que suar a camisa do zero em qualquer um dos casos. Então, nesse aspecto, os três métodos estariam em igualdade de condições.

• Mas, no caso do Wordpress, você poderia criar um plugin especificamente para isso.
• No Symfony, você criaria um Módulo, ou seja, uma visão, um modelo e um controlador específico para este elemento, com o que tudo ficaria perfeitamente estruturado
• E em PHP Puro, dependendo de quão organizado você for, com sorte poderá criar algo suficientemente estruturado para que você continue entendendo daqui a 1 ano, ou alguém que queira te ajudar no processo.

4. A conexão com API de terceiros: Na questão das API, aqui o claro vencedor é o Symfony. Os MVC têm uma integração com API brutal, que simplifica sobremaneira todo o sistema.
No wordpress não está tão mal, porque tem bastantes Helper Functions: https://codex.wordpress.org/HTTP_API que também simplificam a história, embora não de forma tão potente quanto um Framework geralmente
Em contrapartida, em PHP Puro é preciso cozinhar tudo de novo do 0, quase 100%. Bastante incômodo e muitas horas de programação.
Em PHP Puro, talvez você tivesse que recorrer a alguma biblioteca, com os problemas que comentamos antes (se for com Composer, talvez se salve de dar manutenção nela)

5. API própria:
Wordpress tem uma API, mas só para sua estrutura interna, então você teria que desenvolver uma API do 0
Com PHP Puro você tem que desenvolver uma API do 0
Mas aqui o Symfony volta a ganhar: não só você tem a opção de montar um microsserviço com Sylex especificamente orientado a oferecer essa API, como o próprio Symfony também oferece uma plataforma para criar API num instante.

Como tudo isso se traduz em tempo de programação?

Imagine que você fosse um programador PHP sênior, que já conhece amplamente Wordpress, Symfony e, obviamente, sabe programar em PHP puro

Se você começar agora mesmo a programar este site e dedicar exatamente o mesmo tempo todos os dias, o tempo de execução poderia ser:

A) Se escolher Wordpress, poderia demorar entre 1 e 2 meses
B) Se escolher Symfony, poderia demorar entre 2 e 3 meses
C) Se escolher PHP Puro, demoraria entre 4 e 6 meses

Isso sem contar que, em Wordpress e em Symfony, todo o código ficará, em geral, dezenas de vezes mais limpo, organizado, e qualquer um poderá te ajudar no futuro. Em PHP puro, a menos que você dedique muitíssimo tempo a organizar e estruturar a informação e, sobretudo, uma enorme quantidade de tempo a documentá-la, o mais provável é que, com o passar do tempo, acabe se tornando mais um problema do que uma solução

Então, com isso você pode ter uma ideia de por que todo mundo que se dedica ao mundo empresarial foi abandonando paulatinamente a programação em PHP puro e optando por outras soluções de trabalho.

Como disse no início, tanto Wordpress, Symfony e Laravel, tudo se baseia em PHP.

Faça como fizer, em todos os casos você vai usar montes de funções iguais que poderiam ser reutilizadas perfeitamente de um sistema para outro.

Mas uma das grandes diferenças está na comunidade: em Wordpress e em Symfony há dezenas de sistemas que já funcionam, que já estão adaptados e cuja incorporação é imediata. Em contrapartida, em PHP Puro você tem que começar, a cada passo que der, praticamente do 0, o que acaba se tornando um autêntico calvário

Conclusão

Se você acabou de chegar ao mundo da programação e está aprendendo, então PHP é básico e fundamental para começar.

Mas, se já tem conhecimentos intermediários de PHP, então a recomendação, como pode ver, é que passe para um framework, como Symfony ou Laravel

Ou até considere ler a fundo o Codex do Wordpress. Para mim, Wordpress é o caminho fácil quando quero fazer um site eficiente, quando conto com poucos recursos (ou seja, não há uma equipe de vários programadores) e quanto menos se tenha que reinventar a roda, melhor. Eu simplesmente valorizo meu tempo e meu trabalho. E, se posso dedicar 2 horas em vez de 6, acredite que prefiro dedicar 2. Não me importa como, mas neste caso, o fim justifica os meios.

Obviamente, para fazer este artigo o mais curto possível, fui pelo caminho fácil, simplificando tudo ao máximo. Há centenas de considerações a levar em conta. Mas, hoje em dia, não existe um único cenário, do meu ponto de vista, em que valha a pena desenvolver um projeto em PHP puro do 0 (ou em nenhuma linguagem), salvo uma aplicação muito exclusiva, que só vai fazer uma única função e mal vai precisar de um único arquivo com apenas uma centena de linhas, e se exija a máxima eficiência possível. Mas, salvo isso, para o resto dos cenários, o ideal é começar com uma boa base de trabalho, seja um Microframework como Sylex, ou um framework mais avançado como Laravel ou até, como comentei, Wordpress.

Espero que o assunto tenha ficado claro, mas, se houver alguma dúvida sobre este tema, estarei aberto a respondê-la.

muito interessante

Me parece uma grande contribuição para qualquer pessoa que queira começar.

Esses tópicos são muito interessantes, sobretudo para aqueles de nós que queremos começar nisso de programação. Obrigado pela sua contribuição.

Muito bom, mas faltou a recomendação de cursos de PHP.

Muito bom, vai para os favoritos, agradeço uma contribuição tão grande

O problema está na total dependência de um framework; quando esse framework não atende às suas expectativas, o que resta fazer? Fazer código do zero.
Como você diz, o ideal é aprender a linguagem, mas sobretudo aprender a programar e depois se especializar em um framework com a intenção de saber o que estou fazendo.

Muito boa contribuição (y)

absa disse:

O problema está na total dependência de um framework; quando esse framework não atende às suas expectativas, o que resta fazer?

Clique para expandir...

Assim, de primeira, não consigo imaginar esse cenário.

Me dê um exemplo de um Framework não atendendo às expectativas e da necessidade de fazer o código do 0.

Jiren disse:

Muito bom, mas faltou a recomendação de cursos de PHP.

Clique para expandir...

Há milhões de cursos em espanhol. Os da Platzi, para citar alguns, são muito populares.

Mas, pela minha experiência, não conheço duas pessoas que aprendam igual. Um amigo meu detestava os vídeos e só era capaz de aprender lendo livros. Há gente que aprende "fazendo", ou seja, fazendo microexercícios com cada assunto.

Já para mim nenhum desses dois métodos serve, eu só sou capaz de aprender vendo exemplos.

Se você descobrir sua melhor forma de aprender, encontrará os cursos de PHP que melhor vão te servir para aprender.

SirLouen disse:

Me dê um exemplo de um Framework não atendendo às expectativas e da necessidade de fazer o código do 0.

Clique para expandir...

Quando você precisa otimizar o desempenho. Lembremos que os frameworks às vezes contêm coisas desnecessárias que não são utilizadas; para depois tornar os projetos escaláveis não basta só baixar a biblioteca do repositório do composer, já que isso acostuma muitos a não fazer mais nada, e o que acontece quando o programador ou a comunidade não dá mais manutenção à biblioteca e, por consequência, ela não recebe mais atualizações (o ideal é que, se eu sei programar, eu cubra esse highlight de manter a biblioteca atualizada); é aí que está o problema, a total dependência de terceiros.

Digo isso como bom usuário do Laravel, é uma joia, falaria maravilhas dele, mas ao mesmo tempo já tive que entrar no núcleo para otimizar certas coisas ou precisar de alguma alteração específica.

Isso acontece, obviamente. Mas, pela minha experiência, há uma coisa que acontece ainda mais: projetos sob medida que ficam sem manutenção e que, com o passar dos anos, ficam presos em uma versão da linguagem de programação cheia de exploits.

Quando escrevo algo, olho a partir de diferentes premissas, mas para mim, além do tempo que você economiza, que é brutal (tempo economizado que depois pode reinvestir em corrigir essas falhas que encontrar, como a que você comenta), por outro lado, e ainda muito mais importante, se você escolher módulos potentes e com uma comunidade decente por trás, eles transcendem para as novas versões

De fato, há pouco tempo um cliente meu me passou um site, feito em 2010, sobre PHP 5.1 sob medida, inteiro, do 0, o qual caía constantemente por ataques de diversos tipos (principalmente DDoS e consultas massivas aos formulários, que, dada a antiguidade, não tinham nem validação e muito menos validação captcha).

Ao atualizar para PHP 5.3 (que era o máximo que permitia sem quebrar o site, depois de vários testes), percebi que ainda se utilizava a sintaxe antiga de <?=, com o que tive que lintar e refatorar todo o código, o que me levou boas horas.

Em contrapartida, me passaram uma página associada, que estava em Wordpress e no mesmo servidor, numa versão 2.9, e consegui atualizá-la para 5.2.2; o template quebrou só um pouco (que consegui arrumar em apenas 1 hora), e consegui restaurar tudo, e todos os seus plugins (só havia 1 obsoleto, que pude substituir sem problemas), e passei esse site para outro servidor com PHP 7.3 (porque já não poderia conviver em um servidor com PHP 5.3 tão antigo).

Se tivesse sido feita em Laravel, com certeza teria tido sérios problemas também, mas o bom é que, ao contrário da versão com PHP Puro, eu teria podido rastrear as mudanças de funções olhando o registro de alterações, e ir refatorando tudo até fazer o upgrade para a versão 6.

Possivelmente teria me levado pelo menos 10 vezes mais tempo do que no Wordpress, mas a mudança teria sido viável, em comparação com o PHP puro. Por isso, penso, com toda a certeza, que é um erro total programar em PHP do 0. É uma mentalidade imediatista, que, se for um projeto de usar e jogar fora, tudo bem, mas, se for algo a que queremos dar certo grau de perpetuidade, vamos lamentar na maioria dos casos (a menos que seja nosso próprio projeto e lhe demos muito amor e carinho ao longo dos anos).

Hoje em dia, parece que sobra quase tudo, menos tempo.

Muito interessante, obrigado

Eu gostaria de ver como ficaria feito, por exemplo, o sistema de faturamento que temos, seja com Wordpress ou com Symfony, só para ver quão arcaica é a programação do 0 com PHP. Um ponto que não é mencionado e que é um dos principais pelos quais não gosto dos Frameworks é que me parece bastante absurdo ter que carregar no servidor milhares de arquivos (sem exagero) para um site que contém 5 seções simples e que fica pronto com menos de 20 arquivos (contando PHP, CSS, Javascript, etc.) em PHP puro.

Mas enfim, cada um tem sua forma de trabalhar.

Programarte disse:

Um ponto que não é mencionado e que é um dos principais pelos quais não gosto dos Frameworks é que me parece bastante absurdo ter que carregar no servidor milhares de arquivos (sem exagero) para um site que contém 5 seções simples e que fica pronto com menos de 20 arquivos (contando PHP, CSS, Javascript, etc.) em PHP puro.

Clique para expandir...

Fico feliz que apareça alguma alternativa para discussão, mas não muito com esta alternativa em concreto, que me parece trivial demais pelas razões que vou comentando.

Vamos destrinchar um pouco o seu argumento em 2 partes:

Programarte disse:

Um ponto que não é mencionado e que é um dos principais pelos quais não gosto dos Frameworks é que me parece bastante absurdo ter que carregar no servidor milhares de arquivos (sem exagero)

Clique para expandir...

Não tenho muito claro se você está partindo da base de que o armazenamento de "milhares de arquivos", como você diz, é um problema, ou se o carregamento deles na memória, pelo autoloader, é o problema. Mas, em nenhum dos casos, isso é um problema, salvo para um velhinho parado no passado.

Se estivéssemos em 1990 com 200Mb de disco rígido e 8Mb de RAM, eu te daria 100% de razão.
A questão é que estamos em outra era, 3 décadas depois, em que a carga do autoload não ocupa mais de 50Mb de RAM e a soma total dos arquivos mal ocupa 200Mb... numa era em que uma máquina de 512Mb de RAM é de graça (Amazon AWS) e o Gmail te dá 10GB para o seu e-mail, não acho que se preocupar com esses números seja tremendo, e muito menos eficiente. O tempo que você perde superotimizando poderia ser o dinheiro que ganharia simplesmente alugando uma máquina superior; com o tempo, ela se paga sozinha.

Esse é o argumento que vêm usando os programadores de nível muito baixo que estão parados no PHP puro e não são capazes de entender como funciona um Framework. O engraçado é que os testes hoje em dia apontam que, por padrão, Laravel e Codeigniter têm uma velocidade espetacular, e o Wordpress pelado, mais do mesmo. Obviamente um Hello World em PHP executa pelo menos o dobro de rápido que um Hello World em Laravel e pelo menos 4 vezes mais rápido que um Hello World em Wordpress

Mas, no momento em que você começa a programar em PHP, começa a criar ineficiências por todo lado. E o que fazia o PHP puro ser hipereficiente acaba ficando meio lento como tartaruga. Nada de que se orgulhar.

Portanto, esse ponto que não é mencionado não é mencionado por motivos óbvios. O progresso existe para que esse tipo de história fique no passado. Não podemos dizer que as espadas são muito eficientes na guerra porque não consomem pólvora, o que é uma grande economia. Talvez quando saíram as primeiras armas de fogo, que eram muito pouco eficientes e precisas e gastavam muita pólvora, fizesse sentido argumentar isso. Mas, hoje em dia, se você fosse ao exército, te tachariam de louco...

Nota: Se você procurar na Internet, há gente que é contra os Frameworks, porque eles te engessam, te dão uma estrutura que você tem que seguir ao pé da letra. Não te permitem ser livre na hora de criar aplicações RESTful com modelos CRUD amplamente consensuados. Essas pessoas, na minha opinião, são, como vou te comentar no ponto anterior, egoístas que querem fechar seu código a todo custo.

Programarte disse:

Eu gostaria de ver como ficaria feito, por exemplo, o sistema de faturamento que temos, seja com Wordpress ou com Symfony, só para ver quão arcaica é a programação do 0 com PHP.

Clique para expandir...

E a segunda, esta é a melhor parte. Justamente esta é a mágica do Symfony, Laravel ou Wordpress.

Com o Symfony, ele simplifica o processo de criar, estruturar, hidratar, filtrar, organizar modelos, etc, etc, etc... justamente tudo o que você precisa para forjar um sistema de faturamento perfeitamente amarrado, e que, no dia de amanhã, se por acaso alguém precisar te ajudar, ou você não puder continuar programando para ele, a empresa que o usa possa prescindir de você e passá-lo para outro profissional.

E neste ponto você poderia ter razão, dizendo que, ao programar em PHP puro, "sela" melhor seu trabalho com seu cliente, tornando praticamente impossível que seu cliente vá embora com outro programador, dado que o código seja muito pobre e difícil de entender. Mas, caso você seja um verdadeiro profissional e não pense nessas bobagens egoístas, com certeza terá feito um grande esforço para estruturar seu código ao máximo e documentá-lo, não tanto para que outro entenda, mas para que você, daqui a 1 ano, se tiver que fazer uma modificação, se lembre de onde estão as coisas e por que fez aquilo em vez daquilo outro.

Com Laravel/Symfony, organizar e documentar é ninharia: tudo se estrutura tão otimamente bem que voltar a trabalhar no projeto será questão de minutos, independentemente do tamanho do programa
Mas agora vem o melhor: as integrações com módulos de terceiros. Com Symfony/Laravel, você tem uma comunidade espetacular, cheia de repositórios de integração extremamente fácil, com os quais, em um par de funções, poderá integrar dezenas de funcionalidades ao seu programa: integração com CRMs, integração com gateways de pagamento como Paypal ou Stripe, com servidores MTA e suas respectivas API, etc, etc, etc... tudo ficando programado e funcional numa velocidade recorde.

Em contrapartida, em PHP puro isso é um calvário: testar, testar e testar, integrar código e debugar. Com sorte há algum módulo por aí de alguém que integra isso para você, ou, com azar, você terá que recorrer aos snippets que as empresas te dão para usar na sua plataforma.
E depois é preciso modularizar tudo isso, outro calvário, e não errar com os includes, para não acabar incluindo quatro vezes o mesmo arquivo e tudo isso terminar num desperdício de desempenho por todos os lados.
A isso somemos o routing, a solidez do sistema de usuários testado por vários milhares de usuários, a organização dos modelos de dados e a perfeita interconexão entre eles e o banco de dados (sem ter que fazer uma única query na vida e criar inconsistências por toda parte), o uso de um sistema de herança decente com factories, etc, etc, etc...

E quando você chega a dominar isso, tudo é moleza. Algo que você faz rápido, veloz e sem dificuldade, numa velocidade umas 3 e 4 vezes superior a uma programação básica em PHP como a que você propõe.

Tal é a potência de um Framework que até já vi, em alguns plugins de Wordpress, de alguns programadores de peso como a OnTheGoSystems (Toolset/WPML), montarem pequenos frameworks para tentar dotar o Wordpress da mesma arquitetura...

E, finalmente, vou terminar esta resposta com a Joia da Coroa: Wordpress

Como montar um sistema de faturamento TOP em três passos simples:

A) Você instala o Wordpress
B) Instala este plugin: Sprout Invoices https://sproutinvoices.com/features/
C) Entra aqui: https://sproutinvoices.com/features/invoices-for-developers/
Para entender como funciona sua API e seus snippets

E, se mesmo assim faltar algo, você programa com um plugin adicional!! Ou seja, você tem um sistema de faturamento hipercompleto que com certeza satisfaz 80%, se não 90%, do que satisfaria um programa feito por você, mas servido de bandeja em apenas alguns segundos.

E tudo isso por um total de $40 por ano!! $40 é o que vale um programador sênior em uma hora. E uma hora é o tempo que ele gasta para abrir seu IDE, tomar o café da manhã e bater um papo com o colega da mesa ao lado. Ou seja, um sistema de faturamento, sem dúvida alguma, é o pior exemplo que você poderia me dar para comparar um framework ou o Wordpress com um desenvolvimento em PHP puro

Mas, no seu caso, é diferente, porque o que você oferece é um serviço de faturamento para terceiros. Nesse caso, talvez até pudesse aperfeiçoar o plugin com a versão mais top ($149 por ano) e, posteriormente, introduzir os elementos necessários para prover essa usabilidade aos seus clientes. O Wordpress te fornece um sistema de usuários perfeito e, com algum código, você poderá gerar uma plataforma totalmente multiusuário baseada nesse plugin, quase certeza

Ou, na pior das hipóteses, simplesmente poderia partir do Wordpress do 0 e montar, sob um template bem básico, um ou vários plugins sob medida criados por você que cumpram essa função. Assim como o Laravel/Symfony, o Wordpress te fornece essa estrutura. Inclusive, para não usar Custom Post Types, que talvez sejam um pouco ineficientes para certas tarefas (por exemplo, para armazenar os registros das faturas), você poderia pensar em usar suas próprias tabelas. Pode criar um front-end e um back-end sob medida e tudo ficaria perfeitamente orquestrado, investindo com total certeza mais da metade do tempo que você investiu para criar essa plataforma.

Mas, depois de todo esse discurso, tenho que te dizer que, no fundo, te entendo perfeitamente. Se você só sabe programar em PHP, acha que se dá bem nisso e quer conservar seu status quo, obviamente tem todo o direito do mundo de defender essa postura.

Mas vou ser sincero: se eu fosse você, faria um pequeno esforço e começaria a estudar um Framework a fundo urgentemente.
Se não, pouco a pouco, você vai ficando para trás. Embora, se você tiver 60 anos, pelo que falta para se aposentar, também não se preocupe. Em 5 anos a coisa não vai mudar muito, continue fazendo seus programinhas em PHP na raça e vive la vida loca.

👏👏👏👏👏 Excelente contribuição, colega! Obrigado por compartilhar, assim dá gosto pertencer a este fórum.

Interessante, mas incompleto, a meu ver.

Não é necessário saber muito de PHP para aprender um framework; simplesmente, o correto é saber lidar com ele para não ser um escravo do framework e do copy+paste do stackoverflow, como a maioria acaba sendo. Não poucas vezes já vi coisas como "Não sei como fazer isso em javascript, mas sempre copio e colo este jquery e funciona", a ponto de não diferenciarem o que é da linguagem e o que é do framework, por isso fazem coisas que poderiam fazer melhor fazendo-as "vanilla" e não são capazes de usar outra coisa que não seja esse framework ou a cabeça deles explode. Resumindo: aprender diretamente um framework vai te causar problemas.

É verdade que o passo seguinte a uma linguagem do 0 seria usar bibliotecas e frameworks, mas não para substituir a programação do 0, e sim para fazer certos trabalhos que entrem no nicho específico: fazer rápido para fazer barato e que seja rentável, e, depois de entregar, já não será problema seu se a biblioteca ou o framework deixar de ser viável para o projeto em alguns anos (porque o abandonam, p. ex.), e sim do próximo, que terá que mantê-lo e provavelmente só o fará do 0 com outro framework e migre os bancos de dados.

Há muitos casos em que um framework não é o recomendável:

- Se você vai fazer um sistema simples, um framework é matar uma mosca com canhão; aí fazer do 0 é melhor.
- Se você vai fazer um projeto grande e há bom orçamento para tomar seu tempo fazendo bem, atualizando, etc.
- Se você vai fazer algo cujas licenças não sejam compatíveis com as que os frameworks costumam usar.
- Se quer aprender com o que faz e melhorar suas bases (projetos pessoais, p. ex.).
- Se precisa de algo bem otimizado.
- Etc.

Igualmente, se você nunca organizou seus próprios projetos (continuam sendo uma bagunça), eu consideraria ainda não tocar nos frameworks. O MVC e afins não são exclusivos dos frameworks, na verdade são anteriores, e você sempre pode usá-los do 0 ou com bibliotecas.

Algo de que discordo muito do que você disse, como "melhor usar o sistema de usuários do framework, que é mais seguro": esse é um erro bastante comum, que na verdade costuma causar outros bugs piores. Do mesmo modo que se deve aprender PHP do 0, igualmente se deve aprender sobre segurança, de modo que você possa prever se certos códigos podem gerar bugs, sejam vanilla, com biblioteca ou com framework, e não só ter fé cega e acreditar que o framework vai fazer toda a mágica, ou acabarão criando bugs eles mesmos, ainda mais se depois você tiver que corrigir às pressas algo que no framework deixaram malfeito.

PS: Documentar não toma tanto tempo, inclusive há ferramentas para fazer isso mais rápido, e mesmo com elas continua sendo tedioso fazê-lo. Os trabalhos que você fizer com frameworks igualmente deveriam ser documentados, a menos que você não programe nada realmente e seja só uma espécie de configuração, por assim dizer, e por isso a documentação seja tão pequena ou nula que não seja necessário fazê-la.

PS2: Platzi :S

kj2 disse:

Do mesmo modo que se deve aprender PHP do 0, igualmente se deve aprender sobre segurança, o mais a fundo possível, de modo que você possa prever se certos códigos, sejam vanilla, com biblioteca ou com framework, e não só ter fé cega e acreditar que ele vai fazer toda a mágica, ou acabarão criando bugs eles mesmos.

Clique para expandir...

Eu não confio em programações de um único programador em um único site, não porque o programador seja ruim, mas porque ele é incapaz de contemplar milhões de variantes que acontecem no dia a dia. Por mais que você saiba de segurança e de boas práticas, o conhecimento coletivo vai tapando todas as falhas paulatinamente e robustecendo o sistema progressivamente.

Obviamente, quando no seu site entra +1 milhão de pessoas por dia e você pode pagar uma equipe de bons programadores fixos, talvez valha a pena ir um pouco além de alguns desses sistemas de segurança e fazer alguns retoques adicionais para reforçar a história (inclusive com um especialista em segurança ad hoc). Mesmo assim, a facilidade com que se integram medidas adicionais de segurança em alguns sistemas e frameworks, para projetos pequenos com poucos funcionários, é, em contrapartida, uma autêntica complexidade quando falamos de um sistema feito à mão.

kj2 disse:

Não poucas vezes já vi coisas como "Não sei como fazer isso em javascript, mas sempre copio e colo este jquery e funciona", a ponto de não diferenciarem o que é da linguagem

Clique para expandir...

Em certo ponto, eu sabia que alguém ia trazer o jQuery, que é uma maldição para os frameworks porque em algum momento alguém decidiu chamar o jQuery de "framework". 100% das críticas sérias contra os frameworks sempre trazem o jQuery, e tem toda a sua lógica

Concordo com você, mas o jQuery não é um framework, na verdade. JQuery é uma biblioteca e acho que as diferenças são bastante importantes. Um framework contém bibliotecas, mas uma biblioteca não contém frameworks. Por exemplo, se falamos de Javascript, teríamos que falar de BackboneJS, não de jQuery. Também poderíamos falar de Angular ou de React, que seriam MVVM mais que MVC, mas servem para o caso.

O objetivo de um framework é estruturar a programação; já o objetivo de uma biblioteca é simplificar o processo e criar maior abstração. De fato, essa tem sido a tendência desde que a programação começou: passamos de um sistema assembler para uma série de linguagens de programação muito primárias, como COBOL, que abstraíam esse sistema assembler. No meio do caminho, passamos de assemblers a tradutores e de tradutores a linguagens de programação muitíssimo mais abstratas. De C passamos a C++, que abstraía ainda mais tudo, e de C++ passamos a Java e a Ruby, que já eram o ápice da abstração. Hoje em dia existem BPMO em Java que permitem programar um sistema sem escrever uma linha de código.

Mas, mesmo assim, continuo concordando com você, como te dizia há pouco, porque o Jquery, ao simplificar o processo, também engana os sentidos, fazendo com que as pessoas não tenham por que saber como os processos funcionam internamente e possam surgir falsas interpretações.

Mas isso sempre aconteceu historicamente. Lembro que, quando estudava algoritmos, me parecia uma piada ter que aprender os malditos algoritmos quase de cor, para entender que era viável alcançar uma complexidade de (n log n) para ordenar um array com quicksort, quando, na prática, já existiam bibliotecas que faziam o quicksort para você com um include e, simplesmente usando quicksort(variable_array); eu já conseguia o mesmo efeito que ter que decorar tal tralha.

Pessoas com a sua forma de pensar vinham me replicar regularmente: "Mas se você não entende como usa o quicksort, nunca vai saber programar". De todos os programadores que tive na minha empresa, o melhor, sem dúvida alguma, com uma diferença abismal sobre o resto, não sabia programar o quicksort. E acredite que era uma verdadeira máquina.

Então, acho que essa opinião de que é preciso saber como as coisas funcionam para poder usá-las, acho que é, como disse ao colega anterior, a clássica opinião do velho acadêmico, que costuma se apoiar em suas comparações entre um programador novato que tem 2 meses e só aprendeu 20 métodos de jquery, frente a um programador com 10 anos de experiência que domina muito bem javascript em toda a sua extensão.

Mas, se fizermos uma comparação decente, também podemos ter um programador decente, com 5 anos de experiência, que domina amplamente Angular e React, com conhecimentos suficientes de Javascript, que come com farinha o programador puro de javascript com o dobro de experiência, que, no fundo, é um velhinho ancorado no passado (ou um jovem que está no limite 🤣). Coloque os dois para trabalhar no mesmo projeto e eu te garanto, com 100% de certeza, que o programador com 5 anos que domina vários frameworks termina o trabalho na metade do tempo.

E isso eu sei com certeza, porque na minha vida tive que fazer centenas de entrevistas e testes com programadores de diversos tipos.

Como disse ao outro colega, me escute e aprenda a MEAN stack. Não vão te faltar oportunidades nos próximos 10 anos, e não tanto pelos frameworks em si, mas porque, ao aprender isso, você amplia seu cérebro e não fica parado em práticas arcaicas, criando novas conexões sinápticas no cérebro que com certeza facilitam sobremaneira entender novas propostas que forem surgindo nos próximos anos. Em contrapartida, se não der esse passo, você vai ficar parado, e depois vai custar uma verdadeira loucura sair daí.

Minha intenção não é ser purista, é simplesmente que você está recomendando a novatos pular para frameworks e de uma maneira tipo "confie cegamente".

As milhares de variantes, sobretudo no que diz respeito à segurança, realmente acontecem muitas vezes na prática; em código, com saber o básico de segurança já é suficiente até para não pisar na bola, ou pelo menos pisar o mesmo que qualquer framework pisaria.

Qualquer programador aprende frameworks, porque costuma-se exigir velocidade. Indo ao seu exemplo: você coloca o "velhinho" com javascript vanilla e o que tem 5 anos à base de javascript; o de frameworks, claro que vai fazer mais rápido, a diferença talvez seria que o vanilla te entregaria um site que vai ter 100KB de javascript, enquanto o de frameworks te dará um que tenha 800KB e, mesmo assim, no que diz respeito a tempo, se for um trabalho que só precisa ser entregue rápido (como costuma ser para a maioria dos sistemas contábeis e sites simples que se encomendam a empresas), barato e que não há necessidade de mantê-lo realmente (o cliente não vai querer atualizá-lo até que não funcione nem com gambiarra), então o de frameworks, nessa grande maioria de casos, será a melhor opção.

Tanto no que diz respeito à segurança quanto a aprender de verdade, primeiro você precisa de bases. Caso contrário, depois se veem barbaridades de "programadores" que, no que diz respeito à qualidade de trabalho, é equivalente ou até inferior à de um que não terminou o ensino médio e está aprendendo diretamente a "configurar" com frameworks porque procurava emprego e encontrou isso de oportunidade (este é um caso real, por sinal). Claro que todos os trabalhos dessa empresa, de cara para o cliente, vão parecer bons e vão funcionar, embora por trás tenham coisas que depois seria melhor fazer de novo.

No final, que as pessoas se apressem com frameworks e só com isso é o que mais convém ao chefe, mas não o que mais convém ao programador, que terá que ficar se acostumando aos novos frameworks e, por não ter bases, terá que aprendê-los na marra de tempos em tempos e sem possibilidade de julgar se o framework X ou Y é ou não melhor para o seu projeto: enquanto o programador com 5 anos que, de base, começou só por frameworks e é um especialista neles, estará limitado por esses frameworks, sem poder migrar para outros empregos ou cargos, já que não tem bases. O programador vanilla (duvido que com 5 anos; nesse tempo você já aprendeu algum framework e usou mil bibliotecas por obrigação de algum trabalho, já que isso faz parte de aprender o ofício) poderá migrar facilmente, poderá (e deveria) aprender qualquer framework com facilidade, julgá-lo e consertá-lo caso seja necessário (porque sempre há bugs e não é o caso de esperar que "a comunidade" conserte).

Claro, novamente, da perspectiva do "chefe", talvez renda mais contratar um full-frameworks novato e sem bases (o típico mau exemplo de "programador" com frameworks), porque o vanilla, que vai fazer melhor e sabe de frameworks, tem um perfil bem qualificado que, se ele não for bobo, lhe permitiria exigir um salário melhor ou se tornar ele o chefe, coisa que também já vi.

Por sinal, JQuery é sim uma biblioteca, mas isso foi só um exemplo que bem se aplica a qualquer framework ou biblioteca.

Resumindo: o perfil completo de verdade de um programador é saber as bases, dominar o que diz respeito à segurança e depois, como adicional, já que é só um ramo do seu trabalho: saber frameworks, e talvez nem muito, se aquilo a que se dedica não exigir (talvez ele programe os sistemas dos bancos, sistemas de voo, firmwares, eng. forense, inteligência artificial, etc.).

Se você se dedica muito a só um ramo, sobretudo deixando as bases descuidadas, vai te restar a obsolescência e a mediocridade... e ao seu chefe o dinheiro que você fez ele ganhar por sacrificar seu tempo só em frameworks e não em melhorar toda a árvore de habilidades que tinha disponível.

Para fazer isso, melhor abandonar a universidade e pegar uma oficina intensiva de 2 semanas, e assim economiza o tempo de estudo, que depois você vai precisar assim que seus frameworks perderem força.

PS: Quicksort não é algo que se tenha que "programar", é um algoritmo resolvido (aqui o programador já não tem nada a fazer), que você lê na wikipedia; qualquer um que saiba recursividade pode escrevê-lo (atenção, escrever, não programar) em qualquer linguagem.

kj2 disse:

Minha intenção não é ser purista, é simplesmente que você está recomendando a novatos pular para frameworks e de uma maneira tipo "confie cegamente".

Clique para expandir...

Na verdade, acho que você não acompanhou a conversa desde o início.
De fato, recapitulei justamente assim na primeira mensagem (no final, na conclusão), para evitar esses mal-entendidos para aqueles que não tinham lido o outro tópico:

SirLouen disse:

Se você acabou de chegar ao mundo da programação e está aprendendo, então PHP é básico e fundamental para começar.

Mas, se já tem conhecimentos intermediários de PHP, então a recomendação, como pode ver, é que passe para um framework, como Symfony ou Laravel

Clique para expandir...

Por outro lado:

kj2 disse:

O programador vanilla (duvido que com 5 anos; nesse tempo você já aprendeu algum framework e usou mil bibliotecas por obrigação de algum trabalho, já que isso faz parte de aprender o ofício) poderá migrar facilmente,

Clique para expandir...

Suponho que você conta isso por experiência própria. No mundo real, isso nunca acontece. Se você já tem alguém programando confortavelmente com frameworks, raramente ele vai dar um passo atrás.

Geralmente, os que não te falam de frameworks e exaltam exclusivamente as virtudes da linguagem pura é porque já ficaram parados há anos e têm uma habilidade péssima no uso de frameworks. Justamente um dos meus programadores já passou por três frameworks num piscar de olhos (Laravel, Symfony e ZF2) e, a cada salto, demora menos de um quarto do tempo que demorou no framework anterior: observa-se nele perfeitamente uma progressão geométrica de aprendizado. O paradoxal é que, no seu primeiro emprego, ele me contou que começou a desenvolver páginas em Wordpress para uma empresa muito famosa de bebidas na Espanha.

kj2 disse:

Por sinal, JQuery é sim uma biblioteca, mas isso foi só um exemplo que bem se aplica a qualquer framework ou biblioteca.

Clique para expandir...

Usar jQuery é um exemplo que NÃO se aplica a qualquer framework e que, como te disse, sempre se usa para "atacar" os frameworks.
Por isso é importante diferenciar

kj2 disse:

PS: Quicksort não é algo que se tenha que "programar", é um algoritmo resolvido (aqui o programador já não tem nada a fazer), que você lê na wikipedia; qualquer um que saiba recursividade pode escrevê-lo (atenção, escrever, não programar) em qualquer linguagem.

Clique para expandir...

Em contrapartida, essa diferenciação que você faz, sim, se aplica a qualquer cenário, seja uma função como quicksort, que você não pode esquecer que pertence a uma biblioteca (à Standard Library, que não deixa de ser uma biblioteca igual ao jQuery). Mas é que fazer uma diferença explícita entre escrever e programar só acontece em alto nível, numa conversa em que estamos discutindo sobre a base dos frameworks.
Seria como ressaltar a diferença entre cozinhar (pôr a comida no fogo) e cozinhar (todo o ato completo, desde a preparação dos ingredientes até a apresentação do prato).
O mesmo se você usa uma função para enviar e-mail. Aqui você está falando com gente que vai fazer a função passo a passo, tendo que ler toda a documentação relativa a todos os elementos relevantes de um e-mail.
Em vez de simplesmente usar o PHPMailer, que é a biblioteca mais popular do mundo, que você sabe que nunca vai te deixar na mão e que tem um suporte contínuo por trás, adaptando-se a todas as novidades do padrão dos e-mails (e, portanto, nunca vai ficar obsoleta).
Quando implementam a função passo a passo, estão programando ou escrevendo? Estão programando, porque possivelmente não têm a definição na frente. Pois é igual a se alguém conhece o quicksort de cor: pode saber o algoritmo, mas no final pode decidir fazê-lo iterando ou recorrendo. No fundo, programando em qualquer uma de suas formas

O conceito continua sendo o mesmo: para que você precisa "escrever" uma chamada AJAX em javascript se tem a chamada perfeitamente formulada numa chamada jQuery?

Mas talvez você se sinta muito morango, chocolate ou baunilha quando programa em javascript a chamada AJAX com todos os seus componentes, do 0. Prático, eficaz e para todos os públicos. Eu sou mais de Straciatella: e atenção, eu sou o primeiro que programa em PHP bastante à vontade e que tem dificuldade de embarcar no trem dos frameworks constantemente. Sou o primeiro que deveria defender essa postura baunilha. Mas, como você diz, da perspectiva do "chefe", ou de quem orquestra a produção e o avanço, o trem passa 1 vez, e não para mais. E, quando você está dentro, como te disse, a evolução é geométrica. Mas, se não embarcar, no final acontece o contrário: o trabalho que custa embarcar, conforme os anos passam, se multiplica em vez de somar.

E, finalmente, uma reflexão: para que é preciso estar constantemente reinventando a roda?

Nos comentários que você faz, vejo que dá por certas algumas coisas que, embora tenham acontecido com você como chefe, não querem dizer que o resto das situações seja 100% igual. Em primeiro lugar, você dá a entender que o código dos Frameworks é muito mais estruturado que um feito do 0, o que acho que é uma daquelas afirmações que não pode ser 100% real, embora eu tenha que dizer que, efetivamente, a maioria (dos que eu conheci) dos programadores que supostamente são profissionais são realmente uma porcaria para programar e realmente criam código ineficiente, redundante, mal estruturado, etc.

Inclusive eu, em projetos que não têm maior complexidade, transcendência ou importância, não me esforço ao máximo para deixar tudo impecável e nem sequer documentado, pois acaba sendo uma simples página informativa que terá certo período de vida e cujo nível de complexidade, além disso, é tão baixo que, mesmo que você a pegue 3 anos depois, não teria problema algum em entender o que foi feito, nem qualquer outro programador com conhecimentos médios e até básicos.

Por outro lado, por exemplo, num projeto em que estamos trabalhando, que é um Web Service para um programa de fidelidade de uma rede de lojas nacional, onde é preciso programar o necessário para receber as requisições dos POS, fazer processos com a informação e, finalmente, armazenar dados no banco, tudo tem que estar perfeitamente estruturado e a documentação não é opcional (estivesse feito no que estivesse). Não sei se você acha que, nesse tipo de exemplo, onde, por exemplo, não existe uma interface gráfica, também é mais prático um Framework.

Mencionei, ou dei a entender, que não gosto de usar os Frameworks, isso tendo trabalhado com PHP do 0 e com WordPress. E entendo perfeitamente que uns gostem mais de uma coisa que da outra. Do seu ponto de vista, usar PHP do 0 é para velhinhos parados no tempo, e é respeitável; do meu ponto de vista, essa afirmação seria parecida com dizer que os que usam WordPress é porque não sabem programar, mas repito, é o meu ponto de vista.

O argumento que você mais repete e que me parece o mais válido, porque não está sujeito à subjetividade, é que o uso de Frameworks reduz o número de horas de trabalho, e isso na maioria dos casos se aplica perfeitamente, embora, como dizia no início, não em todos, pois, ainda que os sistemas ou simples páginas sejam desenvolvidos do 0, realmente é muito comum reutilizar boa parte de uns projetos ou outros em novos projetos e, de certa forma, acaba sendo mais ou menos a mesma ideia, e que tem a ver com a sua reflexão: não é necessário ficar reinventando a roda uma e outra vez.

Programarte disse:

Por outro lado, por exemplo, num projeto em que estamos trabalhando, que é um Web Service para um programa de fidelidade de uma rede de lojas nacional, onde é preciso programar o necessário para receber as requisições dos POS, fazer processos com a informação e, finalmente, armazenar dados no banco, tudo tem que estar perfeitamente estruturado e a documentação não é opcional (estivesse feito no que estivesse). Não sei se você acha que, nesse tipo de exemplo, onde, por exemplo, não existe uma interface gráfica, também é mais prático um Framework.

Clique para expandir...

Nesse cenário você pode montar um Lumen ou um Symlex (dependendo se você lida mais com Laravel ou Symfony)

Eu acho que é uma necessidade usar um framework, porque em certo grau você padroniza seus processos. Até poderia optar pelo Codeigniter, que tem um footprint muito baixo, com um desempenho de metade do PHP puro, que é verdadeiramente espetacular. Eu não sou muito fã do Codeigniter porque não tem uma grande comunidade por trás.

E, se você é fanático por desempenho, tem o Ubiquity https://github.com/phpMv/ubiquity
Que, parecido com o BackboneJS para JS, simplesmente está ali para estruturar a informação, mas trazendo o mínimo do mínimo. Seria quase como usar um boilerplate com o básico de um framework.

Todas essas opções são ótimas para um servidor headless. Mas, como digo, o importante é a estrutura. Mais até que a velocidade de desenvolvimento. É verdade que se pode usar mal a estrutura, mas pouco a pouco se pega o jeito, se insistir.