Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking frameworks'. Seeing mediocre developers reinvent the wheel, slowly and badly, is super painful and wastes time and money. If you hate the frameworks available to you then perhaps you should consider finding a better ecosystem. Relax your bias and follow the happy developers, wherever that may lead.
I'm not sure I'd describe the golang community's attitude as a complete write-off of frameworks. I don't think I personally know a Go developer who doesn't use some sort of web framework (I personally use Echo, for example).
Rather I think it'd be better phrased as "frameworks should use simple abstractions and methods as often as possible", which the language naturally pushes people towards imo. I believe this causes most Go frameworks to be referred to as "microframeworks".
I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.
Laravel is prime example of a bad framework trying to reinvent the language, educating young developers to use it and its ecosystem and to never get out of the stranglehold.
I'm not sure what made you think it's an "appropriate" framework, it's literally antipattern on antipattern and it's not even the worst thing, neither is the fact it's 10x slower than anything else out there - what's worst is the blatant lying, bunch of security issues and using it as an advertising platform to push subpar services onto devs stuck with it.
I don't know the php ecosystem well at all. I just didn't want to come across as 'Rails is the only one true way'. Lots of php folks seem to love it, and it derives a lot from Rails, so I thought it was a fairly safe shout out. But, it is HN after all, so no opinion can be put forth without and equal and opposite negative reaction.
Or do you prefer to not use any framework and instead write your own one on the fly because you're probably going to do it a lot better with all the best practices and no bugs and great documentation?
Why would you imply I tried to say anything against frameworks in general? My comment was specifically about Laravel because it was singled out as a great framework.
To indulge you, about good frameworks: Symfony, Aphiria. Aphiria in particular because it's small, cuts down on repetitive tasks and doesn't reinvent the language with things like "Macros" or abuse of Reflection or mishandled patterns like singletons - all of which Laravel gets wrong.
Symfony because of active development. Every large tool is bound to be bad at something. Symfony is no exception, however it's not an advertising platform - and Laravel is an advertising platform. Sane choice is to use the tool with maximum benefit and least negative impact.
Micro frameworks that don’t do more than routing. I’d love to see those beautiful reinventions of the wheel people do when using “simple” frameworks for email, ORM, validations, authentication, authorization, cli commands, translations, error and performance reporting, etc etc.
The only case where failing to leverage a good framework would be a real problem is in front end development, and that's just because the front end stack is so horribly designed that it often needs a framework just to make the complexity demanded by business possible. Those frameworks often bring in a ton of problems, of course, so it's really picking your poison. But libraries and hand-rolled solutions should be used when you aren't stuck with JavaScript.
