6 ms·
Both PHP and Go come with everything you need to build web applications in the standard libraries. I have never seen the need for a framework on top of PHP, or
by gregjor 2y ago
Both PHP and Go come with everything you need to build web applications in the standard libraries. I have never seen the need for a framework on top of PHP, or Go, and I have worked with a lot of web code in both languages.
When I have to work with code built on a frameworks -- usually Laravel but I've had to deal with CodeIgniter and several others -- the Achilles' Heel of frameworks becomes apparent: the application gets built around the framework, then framework code and supporting dependencies get updated in breaking ways, and you have to decide to either rework a lot of already working code, or keep what you have and fall more and more behind. That happens with every framework -- I have a project stuck with Bootstrap 3 for exactly that reason.
Go explicitly promises no breaking changes in the language or standard libraries. PHP does not make that promise but has more or less avoided major breaking changes over the years. Why would you give that up to get a little bit of early-stage traction from a framework?
Ideally an application has no external dependencies beyond the language(s) you choose and their standard libraries. Every dependency you add introduces another point of failure out of your control, back-compatibility problems, and possibly the dependency falling into obsolescence, or hijacked for a supply chain attack. I know writing non-trivial web apps without any dependencies seems impossible but I prefer aiming for as close to zero as possible (and carefully vetting every dependency introduced) rather than starting out with a huge set of dependencies such as Laravel or this Go-based clone.
- physicsguy 2y agoSpeed? Familiarity for other developers? I don't think those should be underestimated, particularly for solo devs and small companies just getting started.
- gregjor 2y agoFrameworks do give some early traction, as I mentioned. And lots of PHP devs really only know Laravel, a shame because eventually they will have to debug it or work around limitations. I meant to make the point that frameworks come with a cost, which may get deferred for a while. Maybe that doesn’t matter. For PHP and Go specifically I don’t see the point since the languages have everything you need out of the box.
- muzcoder125 2y agoSorry, I'm going to have to disagree. For most projects, you have to draw the line somewhere, so why pick a point of abstraction where you're likely not to change anything the MVC framework provides? It sounds like you've been bitten by some opinionated frameworks and maintenance pita, also wanting to know as much as possible what code is doing? However, for most web projects it's just not realistic to recode routers, middleware, auth? Most good frameworks provide a solution with materials that are ready to use, quality controlled by hundreds of people, and many thousands of hours. Bootstrap 3 is a perfect example of why you wouldn't pick a UI framework, if you have demands for pixel-perfect design or custom animations you'll be immediately battling the framework in those areas. That doesn't mean all frameworks are bad, like graphic designers rarely use MS Paint and draw each pixel because it would take forever, i.e. you're not being an efficient engineer. If you're building a house, why make bricks yourself, chop trees for wood, or forge custom roof tiles? To me, PHP / Go are themselves abstractions of an enormous amount of complexity, so why stop there, why not go as high as you can imho, higher = less code?
- gjsman-1000 2y agoThis is also another winning point of the framework: Frameworks save you time, and allow you to write less code. By writing less code, it is much easier to understand what your program is doing, and change it as requirements change. When you work without a framework, you invent your own framework. It won't be as well thought through - guaranteed. When changes come in, the sheer amount of code means mistakes will be made and your code will slowly turn into spaghetti. If this is a custom FFMPeg conversion service - totally worth it. If it's CRUD, like how 90% of apps are CRUD, then it's probably a mistake. As I told another programmer, using a framework doesn't mean you are a "semi-skilled" programmer (what elitism). It means you know you aren't special, you aren't smarter than other programmers, you know your own limitations, and know that using a framework other people understand (and keeping the amount of code to a minimum) is the best for your company and the project.
- gregjor 2y agoTry to understand the difference between not using a framework and inventing your own framework. No one in this thread advocated writing their own framework. I originally pointed out that PHP and Go include everything you need to write web applications in the language and standard libraries. They don't need a framework at all. Yes, frameworks have some advantages as you listed. And they have disadvantages. Before doing the same thing over again with Laravel, or Goravel (the original topic of this thread) think hard about the trade-offs. Frameworks impose limitations, on both the application and the programmer.
- gregors 2y agoHaving worked on several projects in the past where the clients had either their own frameworks, and or proprietary languages I think familiarity is highly overrated in most (but not all cases). If you're building something trivial or basically throwaway then familiarity does play a role, but if it's non-trivial all the other costs outweigh any initial learning.
- Mrdarknezz 2y agoYou want to build your own ORM, sockets, SPA, Queue handler, Scheduler, Container, Auth etc? That seems like a massive waste reinventing the wheel
- cjs_ac 2y agoIs it reinventing the wheel, or is it making a new wheel that exactly fits the design requirements? A framework with all the bells and whistles isn't that great when I want a framework with a piano.
- Mrdarknezz 2y agoIf you're making a wheel that exactly fits the design requirements you'll have a hard time when does requirements inevitably changes. Making rigid designs instead of plyable is a terrible idea if you're working with web
- randomdata 2y agoNah. Changing your own code is easy. I dare say it also might be the most fun aspect of programming. Changing someone else's (meaning an external third-party) code can be as easy and fun with the right tooling, but the tooling around supporting that tends to be really bad in most ecosystems. There is a common assumption found around dependencies that their code is theirs and shouldn't be touched except by the hand of the original author. Not impossible to overcome, of course, but with enough friction that you have to seriously consider if it beats simply writing your own. A little copying is better than a little dependency, but a where there is a lot of copying...
- gregjor 2y agoORM: don't need, I can write SQL. Prepared statements sufficient to prevent SQL injection. Both PHP and Go have good database abstraction libraries. Sockets: Don't use but if I did I wouldn't need a framework. SPA: I don't write apps that way. Server-side, which is why we're talking specifically about PHP and Go. Queue handler, scheduler: Can easily do in the database or with Redis. Container: What? Do you mean something like Docker? That has nothing to do with the web app development language or framework. Auth: OAuth2 and SAML not a big deal, but maybe worth introducing a dependency depending on requirements. Regular username/password/MFA auth easy to implement, certainly no framework needed for that. Likewise with routing, "MVC" structure, etc. Frameworks can save some time beginning but eventually you have to debug them, or run into limitations to work around. And one day the framework gets updated and you have to deal with breaking changes.
- solumunus 2y agoIn my experience, SvelteKit is an exception to this rule. It really gives you the absolute bare minimum for the backed.