I always preferred libraries. But they don’t seem to exist for web development.
Using a framework will harm the maintenance of your software
481–490 of 550 posts
Re: Using a framework will harm the maintenance of your software
#482Earlier quoted context omitted.
You identify common aspects and snowflake aspects, and in the end the separation as to which parts are snowflake (contain business specifics). That’s your job as software architect. Again, the locations of snowflake parts tend to be similar across businesses, and this is where good frameworks and CMS tend to offer extension points. It’s a spectrum: a CMS may be more fiddly as to customization but more reliable if you…
I work in startups mostly, where requirements are not defined and the business learns as it goes; it's simply not possible to identify all the areas that are "snowflake" ahead of time. It is sometimes possible to persuade the business that if they create the process in a way that matches the framework it will make life easier for everyone. But often that isn't possible, and often there are good reasons for that.
I see. When writing my comment I also had in mind all the businesses that are not primarily technical (shops and such).
I think it’s often possible to identify the truly inflexible/snowflake aspects the business and still make use of frameworks/CMS. For a tech-focused company there are possibly more cases in which building your own is a viable decision, but with other companies that don’t have strong technical brains so to speak “this will cost you more to develop and more difficult to hire for later” is something they would understand…
Re: Using a framework will harm the maintenance of your software
#483Earlier quoted context omitted.
I tend to make it up as I go along ([0], [1]). It works for me (I just finished up a new SDK, using this technique[2]). However, this would not work for many outfits. It’s just the way that I work. WFM. YMMV. [0] https://littlegreenviper.com/miscellany/forensic-design-docu... [1] https://littlegreenviper.com/miscellany/evolutionary-design-... [2] https://github.com/LittleGreenViper/LGV_MeetingSDK
Hmm… That’s interesting. I seem to have upset people. I’d certainly be interested in knowing why, as my comment directly addresses the parent, and does not coarsen the discourse.
> I’d certainly be interested in knowing why
Don't dwell on it - save your sanity and move on
Re: Using a framework will harm the maintenance of your software
#484"[Frameworks] have different goals than you or your team."
Seems like if that's the case, then you've selected the wrong framework more than frameworks as a whole are bad.
Re: Using a framework will harm the maintenance of your software
#485Earlier quoted context omitted.
Not from the point of view of ISO C and the expected semantics of the abstract C machine.
If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant. This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argu…
Everyone knows Linux is actually written in GCC C, and Google has burned lots of dollars making it work with clang, if it was proper C, that wouldn't never been an issue.
Re: Using a framework will harm the maintenance of your software
#486Earlier quoted context omitted.
I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.
The problem is that they are milquetoast. They are “design decisions” in the same way that white space is technically code style but really distracts from the real elements of style like structure and meaning (don’t create three meanings for the same word, for example). Architecture is much bigger than making sure the doors open the correct direction.
Well, there are many collections of patterns, GoF doesn't claim to be exhaustive. Enterprise Integration Patterns is more high level, for example. But for everyone who hand waves away something like the Strategy pattern as trivial, I have to work with a dozen libraries which accept a massive dictionary of static options to configure their behaviour instead of allowing me to choose an arbitrary, dynamic policy at runtime. I don't think that's a conscious design decision on behalf of most API developers. I suspect it's because the industry largely received the original GoF book as a bunch of cut and pasteable code and later rejected it as symptomatic of Java-esque OO excess. We could instead have received it as a network of signposts telling us what's possible, when and why. Not earth-shattering stuff (neither is Christopher Alexander's original) but useful nonetheless.
Re: Using a framework will harm the maintenance of your software
#487Earlier quoted context omitted.
As a freelancer you only see projects that were in bad enough shape that they needed extra help, no?
Not really. Those bad ones look for outside help when people who maintained all that leave and they don't find in-house devs quickly. Projects that use frameworks tend to maintain opinionated structure that frameworks usually push. Which helps onboarding. Not always, but mostly. And it's always easier to fix and maintain the mess I see for example in a Laravel project, than in built-all-alone project.
I'll rephrase: my suspicion is that there's a survivorship bias here. No-framework setups with poor architecture cause people to leave more often, while no-framework setups that work out are a pleasure to work with.
Re: Using a framework will harm the maintenance of your software
#488Earlier quoted context omitted.
I'd rather wallow in my own mess than wade through someone else's though
The whole point is that there won't be a mess or at least as much of it if you use a framework. How is this so lost on people here so often!
Perhaps because the framework is hiding the mess from you and you have no idea how it is accomplishing critical portions of your application.
Out of sight out of mind.
Re: Using a framework will harm the maintenance of your software
#489Earlier quoted context omitted.
I do agree with that, problem is all the other django-related packages that come with it, especially Django Rest Framework (framework is in the name here). I like some parts of it, e.g. Authentication, permissions, but IMO we often have to bend our code so it fits DRF views, and above all their serializers (which I despise). Obviously we could drop this part of DRF, but it would mean to drop DRF entirely, and I'm not…
What do you despise about their serializers? What would make them better or what would be a better approach for you? (Genuinely curious as someone who's working on a similar idea in a different language)
- They're slow (like really slower than almost any other package, if you use their ModelSerializer)
- They're quite verbose
- Above all, they're trying to do way too much. A serializer should just be about (de)serialization, i.e. converting from a generic format (e.g. JSON) to / back a python object, with some validation. When you use a DRF serializer inside a view, it can do complex queries to retrieve / modify the model instance, save the instance in database, modify the serializer instance with db values (for example because of default values) and return the modified object in the HTTP response. All this logic should not be defined inside the serializer. Obviously you don't have to do it, but it means you cannot use the DRF mixins, nor the viewsets.
On the opposite, I'm in love with pydantic. Like any other package, it has issues, but it tries to solve a single problem, it's concise, validators are explicit and readable.
Obviously I don't mean any disrespect towards DRF maintainers, they're doing an impressive job, a lot of people use and love their work (and I still use it everyday)
Re: Using a framework will harm the maintenance of your software
#490Earlier quoted context omitted.
Well, my point here is that even if there are little patches against a framework, we're talking something like 5% of the repo's code is framework-y stuff. If you've got your own framework, then... what even is the limit? 50%? 90%? I wonder if some of the disagreements in this thread are just like, people in favor of frameworks used Rails/Django, people against them used Spring/Struts. > Framework authors are fallible…
> Yeah, I think that's solved by the "market". The market will settle on "good enough for the average usecase". > But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc. Some of this is a nightmare indeed (e.g. dealing with any web security stuff). Other things are very straightfo…
> Other things are very straightforward, especially when you don't have to deal with 1000 other people's use cases but only your own.
> ... fighting a 3rd party framework ...
Can you give some examples of this? I'm personally finding it hard to come up with examples where this is a significant problem. The closest I can get is I worked on a Django REST Framework project where we went all-in on serializers, but then ripped it out because performance wasn't where we wanted it to be. But it's pretty easy to not use serializers in DRF, so it wasn't actually significant.