7 ms·
You want to build your own ORM, sockets, SPA, Queue handler, Scheduler, Container, Auth etc? That seems like a massive waste reinventing the wheel
by Mrdarknezz 2y ago
You 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.
- the_real_cher 2y agoThat stuff you find easy isnt easy for developers who use frameworks.
- gregjor 2y agoBecause they only know how to program with a framework. Take off the training wheels and learn the language and libraries.
- Mrdarknezz 2y agoI know several languages, and in none of them is it preferable to ignore using the correct tooling.
- gregjor 2y agoRight, that’s my point. We only disagree about what “correct tooling” means. Since PHP and Go have everything needed I prefer not adding more abstractions and dependencies, for less code, fewer black boxes, and fewer external dependencies. Programmers comfortable writing in PHP and Go with their comprehensive standard libraries can also work with frameworks if necessary, but those who can’t get stuck as Laravel developers, baffled by the much larger number of projects and existing code that doesn’t use their “correct tooling.”
- Mrdarknezz 2y agoYou're more productive when you don't have to reinvent the wheel, as I already stated.
- gregjor 2y agoYou know of a way to quantify and measure “productivity” of programmers? Of code? Programmers make claims about productivity and throw the word around, like we all understand what it means.
- randomdata 2y agoNone of those sound like frameworks, just plain libraries that, if integrated properly, are easily swapped out if they become a liability later. Both PHP and Go already provide the framework as part of the standard installation. Everything else you need should be pluggable libraries. If developers are pulling shenanigans with those libraries to try and make them frameworks, beware.