this post was submitted on 07 Oct 2023
1 points (100.0% liked)
Programming
46 readers
2 users here now
This magazine is dedicated to discussions on programming languages, software development, and coding. Whether you are a beginner programmer or an experienced developer, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as coding languages, software engineering, web development, and more. From the latest trends and frameworks to tips and tricks for debugging, this category covers a wide range of topics related to programming.
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Frankly yes if you’re doing it in a commercial setting, and probably if it’s a hobby. Frameworks like Rails or Django handle a lot of stuff you probably don’t want to and don’t know how to build right. You may want to learn how they work and jump in to futz with stuff to get it where you want it but you don’t want to build a lot of stuff yourself. There are security risks if you do that may be mitigated by the framework maintainers already, optimizations and edge case handling that you need to be aware of, and standards you might have to meet. I think at best you would end up rewriting a lot of the same functionality that’s in a framework.
A better or more sustainable option might be to learn how all these middleware and low level components work so you can form educated opinions on configuration and implementation
I strongly disagree with this. As with all engineering tasks, it comes down to what you're trying to solve.
If a framework can do some significant lift for you, then it's a question of whether learning it is worth the time and effort saved in writing a bespoke solution that does what the framework offers. You also have to measure how "locked in" to the framework you'll become and whether or not that will be a problem for you.
One example of a framework I wish I never touched is React Native. The way React Native handles everything from dependency management to coding practices to how to handle breaking changes is nightmarish. More than once on a React Native project did the entire project explode for reasons such as wildly major refactors (with only 6 to 12 months given for folks to switch over), "clever" code having wacky ambiguities and conseqent side effects, a convoluted toolchain breaking somewhere in the middle, and even the package manager itself being conceptually problematic (which I understand is not the fault of React Native but still) I am convinced the team lost more time in learning and coping with the idiosyncracies of the framework than if the project had just been written in Java and Obj C with some useful libraries.
One example of a framework (or game engine or whatever you'd want to call it) I adore is Monogame. Monogame is super straight forward. You're given a game loop, I/O handling, and some additional niceties. Nothing is obfuscated from you. The tools you use, with the single exception of the MGCB, are whatever you want to use. There's no magic. Everything is right there in plain ol' C# for you to see and understand clearly.
As you rightly point out, some tasks are both critical and complex (e.g., cryptography) and shouldn't be performed on one's own. Choosing a framework or a library that will handle that for you is prudent. However, most of the features of a framework are not that. Most features are about solving boilerplate and general issues for you so you can get to the task of writing whatever it is you're trying to write. That's all well and good. However, choosing a framework can come with as many headaches as they relieve, if you're not diligant.
well said bro